One balance, one set of rules, redeemed the same way at every register and on the website.

Why "works at POS too" is the hard part

Most custom programs are scoped online first. The register is an afterthought, and it is where programs break. Staff cannot see a balance, a rule that works at web checkout is invisible at POS, a customer is applied to the wrong sale, and the reconciliation report has a gap nobody can explain. For a retailer with eight stores, the register is most of the program.

We scope the register first. What does the staff member see when a program customer walks up? What do they tap? What happens when the customer's cart has something the program does not cover? What do they say when someone claims a balance that is not theirs? Every one of those has an answer in the build and in the training notes.

What Shopify POS does natively, and what it does not

Natively: attach a customer to a sale, apply their store credit balance as a payment method, apply automatic discounts, and run cart validation Functions. That covers the basic redemption.

Not natively: show which program a balance came from or what it can buy, show remaining allowance separately from the store credit balance, issue program credit with a reason, verify identity before applying a balance, or explain a blocked cart in program terms. Those are the gaps a POS UI extension fills.

What the build includes

Native redemption, configured properly

POS Pro on the right locations, POS app version checked, new customer accounts enabled, store credit visible as a payment method, and a test transaction at every location before launch. This sounds basic and is skipped surprisingly often.

A POS tile for the program

One tile staff tap for everything program related: look up the attached customer's program, balance and remaining allowance; see what the program covers; issue credit on the spot where your policy allows it, with a reason code that appears in the report; and, for higher-value programs, a prompt that asks staff to confirm one identifying detail before the balance is applied.

Rules enforced at the register

The same cart validation Function that protects web checkout runs at POS. A safety-only program with a hoodie in the cart is flagged before payment, with a message written for a staff member reading it aloud, not for a developer.

Location-aware where it matters

Programs limited to certain stores. Pickup and delivery options by location. Reporting by store and, where you want it, by staff member, so a program manager can see that store four issues twice as much on-the-spot credit as the others and ask why.

Staff training notes, written with the build

Two pages, not a manual: what changed at the register, the three things to tap, the identity script, and who to call. Delivered before launch, revised after the first week from what staff actually asked.

Fits with

This is the register side of a store credit program or corporate account program. The rules are the Functions described on that page. The numbers land in the reconciliation report.

Other custom builds

• Store credit and voucher programs: Company-funded credit, allowance programs and rewards paid in native Shopify store credit, with pools, rosters, expiry and a reconciliation report.
• Corporate accounts and invoicing: Company accounts where staff buy under one program and the company gets one invoice, built on Shopify B2B companies, payment terms and draft orders.
• Checkout extensions and Shopify Functions: Custom discount, payment, delivery and validation rules that run inside Shopify checkout, plus checkout UI that shows the right thing to the right buyer.
• Integrations, automation and reporting: Klaviyo, Shopify Flow, accounting and ERP hooks, plus the reports your finance team needs to invoice and reconcile a program.

Or read the overview: custom Shopify Plus development for merchants over $2M a year.

Programs that work at POS and online: common questions

Does Shopify POS accept store credit at the register?

Yes. Shopify POS has redeemed native store credit since 2025 on POS app version 10.2 and later, for stores using new customer accounts. The staff member attaches the customer to the sale and the available balance can be applied as payment. It is the same balance the customer sees online, so there is one number, not two.

Does POS check that the person is who they say they are?

No. POS applies the balance to whichever customer the staff member attaches to the sale, with no verification step. For a program where balances are worth real money, that is a staff training item: confirm the name and one other detail before attaching the customer. We write that script into the launch notes, and for higher-risk programs we build a POS UI extension that adds a check.

What is a POS UI extension?

A screen inside the Shopify POS app that your staff open from a tile. We use them for things the register does not do on its own: look up a program balance and remaining allowance, issue credit on the spot with a reason code, check whether a cart is covered by a program before ringing it up, or show a customer's company and cap.

Can program rules apply at the register the same way as online?

Yes. Cart validation Functions run at POS as well as web checkout, so a program that covers safety products only, or a company cap, is enforced in both places with the same message. Staff see it before payment rather than a customer finding out later.

We have eight stores. Do rules differ by location?

They can. Location is an input to the rules, so a program can be limited to certain stores, delivery and pickup options can depend on location, and reporting can be split by store. Most programs run identically everywhere, which is the point, but the option is there.

What do you need from our POS setup?

Shopify POS Pro on the locations running the program, the POS app on version 10.2 or later, new customer accounts enabled, and a list of the staff roles that should see the extension tile. We check all of that in scoping.