Accessible Store Credit: Balances, Codes, and Checkout Fields
Store credit fails shoppers in quiet places: balances behind image codes, credit codes read as one long string, and checkout fields that reject pasted codes. The checks that fix it.
Store credit should be the simplest money on a site. It is a balance and a code. Yet the flow manages to stack barriers end to end: the balance lives inside an emailed image, the code is a sixteen character string with no grouping, and the checkout field clears itself when a screen reader user pastes into it and moves on.
Credit also arrives at a sensitive moment. Much of it is issued as a return resolution or a service apology, to a customer who has already had one bad experience. A credit they cannot spend without help is not a resolution. It is a second problem with a balance attached.
The balance has to exist as text, somewhere they control
A balance checker that asks for a code and a PIN, then shows the result as a styled graphic or a fleeting popup, fails the basics. The result needs to be real text, announced as a status message, and persistent on the account page for signed-in customers, not only behind the checker. And the email that delivers the credit should state the balance and the code as plain text in the body. An image-only credit email is inaccessible before the website even gets a chance to be.
Codes themselves need mercy built in. Group the characters visually in fours, accept the code with or without spaces and dashes when it is typed or pasted, and never use a font where capital I, lowercase l, and the number 1 are indistinguishable. That last one is a design detail that support teams pay for in tickets, from customers of every ability, reading a code off a phone in poor light.
Checkout is where credit quietly dies
Test the redemption field with the tools people actually use. Paste the code rather than typing it. Apply it, then apply a second code or a discount, because the rule for whether credit stacks is usually explained in small text that appears only after an error. If applying credit wipes a discount without warning, or the reverse, the shopper learns the store's policy by losing money, and a screen reader user may not learn it at all if the change is not announced.
Error handling deserves the same care as any payment field. A rejected code should say why in words, invalid, already used, expired, and keep the rest of the checkout intact. The balance remaining after a partial spend should be shown on the confirmation and in the account, as text, with the same code still working for the remainder. Partial redemption is where many platforms quietly strand small balances, and small balances belong to customers too.
The support script is part of the flow
When credit fails, the customer contacts support, and what support can do decides whether the barrier was an inconvenience or a wall. Agents need a way to read a balance, reissue a code in an accessible format, and apply credit manually to an order. If the answer is that the customer must use the website, a website they have just explained they cannot use, the store has made its position clear. Put the manual path in the script before you need it, not during the chat.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Accessible Virtual Try-On and AR Fit Tools: The Fallback Is the Feature, Accessible Build-a-Box Flows: Multi-Step Customisation Without the Traps, and Accessible Preorder and Deposit Flows: Dates, Balances, and Honest Timers.
Frequently asked questions
How should a store credit balance be displayed?
As real text on the account page and in the credit email itself, not only as an image or a temporary popup, and announced as a status message when a balance checker returns it.
What makes a credit code hard to use?
Ungrouped long strings, fonts where similar characters look identical, and fields that reject spaces, dashes, or pasted input. Group characters in fours, accept flexible formatting, and allow paste.
Should applying store credit remove a discount code?
Only with a clear warning and an announcement of the change. Silently swapping one for the other teaches shoppers the policy by costing them money.
What should support be able to do when credit fails?
Check the balance, reissue the code in plain text, and apply credit to an order manually. An inaccessible redemption flow with no manual fallback strands the customer completely.