How to Switch Gift Card Providers on Toast POS

What happens to your outstanding balances

Every unredeemed gift card you have sold is a liability sitting on your books and a promise sitting in someone's wallet. When you change providers, that liability does not evaporate and the promise does not expire. It gets moved. Your outgoing provider produces a file of every active card and its remaining balance, and those records are loaded into the new program before the switch happens. On the morning after cutover, a guest hands over the same card they were given last Christmas, it scans on the same Toast terminal, and the same balance comes off the check. Nothing about the moment tells them anything changed.

What actually changes is where the balance lives and who answers for it. Before cutover, authorisation runs against your old provider's platform. After, it runs against the new one. The card number on the plastic is unchanged, so guests keep their cards and you keep your card stock — you order new plastic when you want a new design, not because you switched.

The liability figure should reconcile exactly. Compare the total outstanding balance on the final file from your old provider against the total loaded into the new program, and confirm the card count matches as well as the dollars. Do that before you go live, not in the following month's reporting. If the two numbers disagree, the difference is almost always activity that landed after the export was cut — which is what the delta file exists to catch.

Cards break in exactly one scenario: a restaurant cuts the old provider off without moving the file first. That is a planning failure, and it is entirely avoidable.

The balance export file

The whole migration rests on one unremarkable artefact: a CSV your current provider exports listing every card that still has value. It is not a specialised format and there is no industry standard behind it, which is why asking for it plainly matters more than asking for it technically.

Three columns do the work. Card number is the identifier printed or encoded on the card, and it must arrive exactly as it appears on the plastic — full length, leading zeros intact, no truncation and no spaces or dashes invented by a spreadsheet. Remaining balance is the current unredeemed value on that card, in dollars and cents, as of the moment the file was cut. Activation date is when the card was first sold and loaded; it is not strictly required to make a card work, but it is what lets your accountant age the liability and it is the column most often left out.

Useful extras, if the provider will include them: the location that sold the card, the last activity date, and a status flag separating active cards from ones already zeroed out or cancelled. None of these are worth delaying the migration over.

Ask for it as a CSV rather than a PDF or a screenshot of a dashboard, and ask for the whole file rather than a report capped at the first thousand rows. Open it before you accept it: check that the row count looks like your card count, that balances are numbers rather than text, and that at least a handful of card numbers match cards you can physically pick up and read. Two minutes of inspection here prevents the most expensive failure mode in the whole process.

If your current provider stalls or refuses

Some providers hand the file over the same day. Others discover a queue. Slow-walking a departing customer is a retention tactic, and the counter to it is a written request with a date on it — an email creates a record, a phone call does not.

Keep it short, unemotional, and specific about the format. Something like this:

Subject: Balance export request — [restaurant name], account [number]

Hello, we are transitioning our gift card program to another provider. Please send a complete export of all outstanding gift card balances for our account in CSV format, including card number, remaining balance, and activation date for every active card. We would like to receive the file by [date]. Please also confirm the process and lead time for a final delta export on our cutover date. Thank you.

If the date passes without a file, follow up on the same email thread so the timeline is visible in one place, and copy anyone senior you have dealt with. Check your agreement for language covering data on termination — most contain it — and quote it. Your card data describes obligations your restaurant owes to your guests, and a provider who will not return it is worth documenting.

In the meantime, keep moving. Design work, Toast configuration, and staff training can all proceed while the file is outstanding, so the day it arrives you are loading it rather than starting. And if the file genuinely never comes, there are fallbacks — reconstructing balances from historical reporting, or honouring older cards manually for a defined period — but treat those as last resorts rather than the plan.

Day-by-day cutover timeline

A switch fits comfortably into five business days once the export is in hand. Pick a week without a holiday, a big private event, or a menu change in it.

Day 1 — Request and configure. Send the balance export request to your outgoing provider with a firm date. In parallel, hand over your Toast Restaurant GUID and confirm Partner Integrations access on the account so Factor4 can begin the configuration through Toast Integrations Support. Approve card artwork if you are refreshing the design.

Day 2 — Receive and inspect the file. Open the CSV, check the row count against what you believe your outstanding card count to be, and confirm card numbers are full-length and balances are numeric. Reconcile the total outstanding liability against your own books and raise any gap immediately rather than at go-live.

Day 3 — Load and test. Balances are loaded into the new program and a sample of real cards is checked to confirm the balance shown matches the balance expected. Test high-value cards, near-zero cards, and cards issued a long time ago, not just the convenient ones.

Day 4 — Train the floor. Walk every shift through selling and redeeming a card on the Toast terminal. The workflow is the same tender flow they already know, which is the point, but the person on the register at 7pm on cutover day should have done it once with their own hands.

Day 5 — Delta and go live. Take the final delta export from your outgoing provider covering everything sold or redeemed since the first file, load it, and cut over. Choose a slow daypart rather than a Friday dinner. Watch the first evening's redemptions, and keep the old provider's contact reachable for one more week.

What goes wrong when it's rushed

Migrations that fail rarely fail technically. They fail because a step got compressed to make a date, and there are three places that happens.

Cutting over before the final delta file

The first export is a photograph, not a live feed. Every card sold, redeemed, or reloaded after it was cut is invisible in that file. Go live on Friday using Tuesday's data and Wednesday's holiday buyer arrives with a card the new system has never heard of, while a card that was drained on Thursday shows its old, pre-redemption balance and gets spent twice. Both errors happen at the counter, in front of the guest, and both are fixed by loading a delta file on the morning of the switch. It is the least glamorous step in the process and the one that decides whether the week goes smoothly.

Card number format mismatch

Card numbers get mangled between systems more often than anyone expects. A spreadsheet drops leading zeros, converts long numbers to scientific notation, or stores them as text with stray spaces. A provider exports an internal reference rather than the number encoded on the plastic. Whatever the cause, the symptom is identical: a guest's card scans, and the system says no such card. The prevention is to test with physical cards from your own drawer before go-live, comparing what is printed against what is in the file — and to move the CSV around as a CSV, not through a spreadsheet that helpfully reformats it.

Untrained staff on day one

The redemption workflow lives inside Toast and looks like the tender flow your team already uses, so training is short. Skipping it anyway is still the most reliable way to make a clean migration feel broken. A server who has never processed one hesitates in front of the guest, and hesitation reads as "your card is a problem." Spend fifteen minutes per shift selling one card and redeeming one card on a live terminal, and make sure closing managers know who to call. Guests forgive a slow transaction; they remember being told their gift card might not work.

If your group runs more than one restaurant, plan the cutover as a group event — Toast allows a single provider per restaurant group, so every site moves on one date. That is also the moment to fix balances that never travelled between your locations in the first place, which is what a multi-location gift card program is for. And if you are still deciding whether the switch is worth it, the full cost breakdown for a Toast gift card program is the other half of the decision.

State-specific considerations

Changing providers is also the moment your unredeemed balances get counted. Unclaimed property (escheatment) rules are set state by state: some exempt gift cards outright, others set a dormancy period after which part or all of an unredeemed balance is reportable to the state. Whichever applies to you, the migration file you receive from your outgoing provider — card number, remaining balance, activation date — is the same data your accountant needs for reporting, so keep a copy of it.

We are building a per-state reference covering the dormancy period, the annual holder reporting deadline, and whether gift cards are exempt:

These pages are general information rather than legal or tax advice — confirm your obligations with your accountant before you report.

Questions, answered

Switching providers on Toast

Will cards guests already hold stop working when we switch?

Not if the migration is done properly. Outstanding balances are exported from your current provider and loaded into the new program before the cutover date, so a card in a guest's wallet keeps its remaining balance and keeps redeeming at your restaurant. Cards only stop working when a restaurant switches without moving the balance file first — which is a process failure, not a technical limitation.

Do guests need to swap their cards for new ones?

No. The card number printed on the plastic is what carries over, so the same card a guest has had in a drawer since last December still scans. You order new stock when you want a new design or when you run low, not because you changed providers. Reissuing cards is the outcome you are migrating specifically to avoid.

How long does the whole switch take?

Plan on about a week of elapsed time once your current provider produces the balance export. The technical work is short — the schedule is driven by how quickly the outgoing provider responds and by picking a cutover moment that does not land in the middle of service. Restaurants that start the request early and pick a slow weekday go live comfortably inside five business days.

Can we do this during the holidays?

You can, but it is the worst time to try. December is when the largest share of your annual gift card volume moves, so it is when a mistimed cutover costs the most and when staff have the least attention to spare for a new redemption workflow. January and the shoulder weeks of the year are far better. If a contract renewal is forcing a December date, say so early so the delta file and staff training get planned around your busiest shifts.

Does Toast allow more than one gift card provider at a time?

No. Toast allows a single gift card provider per restaurant group, which is why the switch is a clean cutover rather than a gradual overlap. Every location moves on the same date, and that date is the same date your outstanding balances transfer. It also means you cannot run the old and new programs side by side to test — the delta file exists precisely because that overlap is not available.

What happens to balances sold between the export and the cutover?

That gap is what the delta file covers. Your outgoing provider produces a second, smaller export on the morning of the cutover listing every activation, redemption, and reload that happened after the first file. Loading it immediately before go-live means a card sold two days before the switch carries the correct balance afterward. Skipping the delta is the single most common way a migration goes wrong.

What do we need from Toast?

Partner Integrations access on the account, and your Toast Restaurant GUID — the identifier attached to each restaurant or to the group. If you subscribe to the Restaurant Management Essentials or Pro suite you already have the access; below those tiers it gets added first. From there Factor4 works the configuration through Toast Integrations Support and tells you the date it goes live on your terminals. You are never the middleman between two vendors.

What if some of our locations aren't on Toast?

They still join the same program. Factor4 is POS-agnostic, so balances sit in one pool across the group and a card sold at a Toast restaurant redeems at a location running something else, at the same balance, in real time. For a mixed group that is usually the reason for switching in the first place.

Switching gift card providers on Toast — without voiding cards guests already hold

Get your free quote