# Bespoke POS UX: How to Rearrange Checkout Buttons and Modify Transaction Steps Safely Under PCI Compliance

> Published: 2026-10-23
> Updated: 2026-10-23
> Author: Jackson Mclean
> Category: POS
> Canonical: https://finalpos.com/blog/rearrange-checkout-buttons-pci-compliance

PCI compliance follows the card number, not the button layout. Which checkout customizations are safe, which ones pull a device into scope, and how to ship changes without breaking a shift.

You can rearrange checkout buttons, rename them, and add or reorder transaction steps without touching your PCI compliance. One rule has to hold: card data never passes through the part you customized. PCI DSS (the card industry's security standard) follows the card number, not the layout. Put Cash ahead of Card, add a loyalty lookup, move the receipt question, and your compliance picture stays the same. Add a field that captures a card number, and the device running that screen joins the systems an assessor cares about.

The PCI details below reflect PCI DSS v4.0.1, the only active version since v4.0 retired at the end of 2024[¹](https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1). A v5.0 is in development[²](https://www.tevora.com/resource/preparing-for-pci-dss-v5-0-what-we-know-what-we-dont-and-what-to-do-next/), so treat the specifics as a snapshot, accurate at publication.

## Why doesn't moving a checkout button change your PCI scope?

Because PCI scope (the systems the standard covers) is defined by what touches card data. The standard applies to anything that stores, processes, or transmits cardholder data, or could affect its security[³](https://www.pcisecuritystandards.org/faqs/1579/). A button labeled Card that sends an amount to a terminal does none of those things.

The terminal does the sensitive work. In a well-built setup, the card is read and encrypted inside a PCI-approved payment device and stays unreadable until it reaches the processor's secure environment[⁴](https://listings.pcisecuritystandards.org/documents/P2PE_At_a_Glance_v3.pdf). Your checkout screen gets back an approval and, at most, the last four digits.

It doesn't matter who wrote the screen: a developer, an agency, or someone who [vibe coded a point of sale](/blog/vibe-coding-a-point-of-sale) over a weekend. For any customization, ask one question: did the path the card number travels change?

![Shop owner rearranging checkout buttons on a tablet POS next to a paper layout sketch, a customization that stays outside PCI compliance scope](https://storage.googleapis.com/final-os-media/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/c6127d4b8f45cb8f-bespoke-pos-ux-rearrange-checkout-buttons.png)

## Which checkout customizations are safe to make?

Anything that shapes the experience around the payment without handling the card:

- Reorder, resize, rename, or recolor payment buttons. A market stall that runs mostly on cash can put Cash first; a cafe can make Card the big button.
- Add steps before payment: dine in or takeout, a loyalty lookup by phone number, an upsell prompt, a confirmation for age-restricted items.
- Add steps after payment: email or text receipts, a feedback question, an automatic reset for the next customer.
- Choose which tenders appear, including split payments and gift cards.

Phone numbers and emails fall under privacy law, but they are not cardholder data and do not expand PCI scope.

## Which changes pull your checkout into PCI scope?

Any change that lets card data appear on, or pass through, a screen you control:

- A custom card number field. Keyed-in phone orders belong in your payment provider's built-in manual entry, not a field you added.
- A homemade "save this card" step. Storage puts the storage system in scope, and card security codes must never be kept after authorization[⁵](https://blog.pcisecuritystandards.org/faq-can-cvc-be-stored-for-card-on-file-or-recurring-transactions).
- Full card numbers on screen. PCI DSS requires card numbers to be masked when displayed (Requirement 3.4.1)[⁶](https://www.pcisecuritystandards.org/faqs/1492/), including on custom receipts, order screens, and staff reports.
- Logs and recordings. Debug output, screen recordings, and training screenshots taken during payment capture whatever the screen shows.
- Replacing the provider's payment step with one you wrote. That moves the card path into your own code, the same gap that shows up [after the UI in general-purpose app builders](/blog/build-a-pos-with-lovable-or-replit).

The usual pushback: if the payment provider is PCI compliant, isn't that enough? It covers the provider's systems, not a card field you added or a log you kept. A compliant provider shrinks your share of the work, and your customizations decide whether it stays small. It's the same reason [generated code should never see a card number](/blog/gemini-3-6-flash-pos-real-payment).

The paperwork follows the same line. Each self-assessment questionnaire (SAQ, the compliance checklist most small merchants complete) is written for a specific setup, based on how a business handles card data[⁷](https://pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/what-is-the-intent-of-the-saq-eligibility-criteria). A checkout where cards only touch a certified terminal generally fits the shorter ones. A custom card field can move you to a longer one, and your payment provider or acquirer (the bank that sponsors your card acceptance) decides which applies. We mapped [how steep that questionnaire ladder gets](/blog/pci-compliance-for-app-developers), and attestation is one of the [launch costs that stay fixed](/blog/gemini-3-8-flash-pos-launch-cost) however the screens get made.

![Customer tapping a card on a separate unbranded payment terminal, keeping card data out of the customized checkout screen for PCI compliance](https://storage.googleapis.com/final-os-media/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/8340005bf1914e70-bespoke-pos-ux-card-on-terminal-only.png)

## How do you ship checkout changes without breaking a shift?

PCI covers half of "safely." The other half is not breaking a checkout mid-rush:

- Keep destructive actions away from the pay button. Refund, void, and clear cart should never sit where a thumb lands during a lineup, and each deserves a confirmation step.
- Change one thing per release, so if refunds or voids jump the next day, you know why.
- Test the whole sale before going live: cash, card, split payment, a refund, and a declined card.
- Deploy between orders, never mid-transaction, and keep the previous version ready to roll back.
- Watch the first shift. A cashier hesitating over a moved button is the cheapest bug report you will get.

![Store manager testing a customized POS checkout after closing before deploying it, the safe way to ship checkout changes](https://storage.googleapis.com/final-os-media/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/0985b61786f1bbd0-bespoke-pos-ux-test-after-hours.png)

## How does Final split the checkout from the card?

In Final, the flow you design decides which payment buttons appear and what they say. When a cashier taps the card button, the amount goes to the connected reader, Tap to Pay, or a paired cloud terminal. The customer taps, inserts, or swipes there ([how a payment works at checkout](https://finalpos.com/help/take-a-payment)). Final Pay is PCI DSS Level 1 compliant, and full card details are held by Final's payment processor, never stored by Final ([Getting Started with Final Pay](https://finalpos.com/help/getting-started-final-pay)). Flow Studio has a test view for trying changes and runs a pre-flight review before every deploy. Stations can pick up a new version between orders, and earlier versions stay available for rollback ([how to build and deploy your first flow](https://finalpos.com/help/build-your-first-flow)).

## So, can you customize your POS checkout without breaking PCI compliance?

Yes. Rearrange, rename, add, and remove steps freely, as long as the card number never touches a screen you built. Rule of thumb: **if a change makes card data visible, typeable, or storable anywhere new, ask your payment provider first.** If it doesn't, test it, ship it between orders, and keep a rollback ready. To see how a checkout change gets described and deployed, start with [Getting Started with Flow Studio](https://finalpos.com/help/getting-started-with-build).

## FAQ

**Q: Can I rearrange checkout buttons without affecting PCI compliance?**
A: Yes, as long as card data never passes through what you changed. PCI DSS covers systems that store, process, or transmit card data, so reordering, renaming, or recoloring checkout buttons stays outside PCI scope while the card is read on a certified payment terminal.

**Q: Is a customer's phone number or email covered by PCI DSS?**
A: No. PCI DSS covers cardholder data such as the card number. Phone numbers and emails collected for loyalty or receipts fall under privacy laws, but they do not expand PCI scope.

**Q: Can I add a save card option to my POS checkout?**
A: Only through your payment provider's built-in card storage. A homemade save-card step puts your own storage system in PCI scope, and card security codes must never be stored after authorization.

**Q: Can I type card numbers into my POS for phone orders?**
A: Use your payment provider's built-in manual entry for phone and mail orders, not a card field you added yourself. A custom field moves card data through a screen you control, which pulls that device into PCI scope.

**Q: If my payment processor is PCI compliant, am I automatically compliant?**
A: No. A compliant processor covers its own systems and shrinks your share of the work, but merchants still validate their own setup, usually with a self-assessment questionnaire that matches how they handle card data.

**Q: Which PCI DSS version applies in 2026?**
A: PCI DSS v4.0.1 is the active version; v4.0 was retired on December 31, 2024. A v5.0 is in development, so check the PCI Security Standards Council for updates before your next assessment.

**Q: How do I test POS checkout changes before going live?**
A: Run every sale path before deploying: cash, card, split payment, a refund, and a declined card. Change one thing per release, deploy between orders rather than mid-transaction, and keep the previous version ready to roll back.