Marketplace Store Credit, Wallets, and Gift Cards
These three things land in the backlog as marketing features: "let's add gift cards before the holidays," "let's let support issue a voucher." They are a line on the balance sheet, sometimes a regulated activity, and in a marketplace also a mechanism that moves money between you and your sellers. It moves that money in a direction nobody planned.
The cost of the wrong answer is deferred and therefore sneaky. You sell the card in November and you pay for it in March, to somebody else, out of an account that no longer holds it.
Marketplace store credit, a buyer wallet, and a gift card are three forms of one thing: stored value, which sits on your balance sheet as a liability toward the buyer. They differ only in whether money ever came in for it.
When that balance is spent at a third-party seller, the seller still has to be paid in real money, so the value you issued leaves your account and goes to somebody else. On a €1,000 order paid half by gift card, that is €380 you top up today out of money you received six months ago.
This article breaks down:
- What do a wallet, store credit, and a gift card have in common?
- Should a gift card be a payment or a discount?
- Who funds store credit, and how does the seller see it?
- When does a wallet become a regulated payment instrument?
Key insights
- All three are one subject: a liability toward the buyer. The only difference between them is whether money ever came in for it.
- A gift card has to work as a form of payment. Built as a discount, the seller silently co-funds your promotion and the liability leaves your books unsettled.
- Store credit needs a named funder at the level of a single order line: you, the seller, or both in an agreed proportion.
- A wallet crosses into regulation the moment a buyer can put money into it for which nothing has been delivered yet.
- Tax on a marketplace voucher usually falls due at redemption, so your data model has to connect a redemption back to a sale six months earlier.
What do a wallet, store credit, and a gift card have in common?
A wallet, store credit, and a gift card look like three separate subjects. They are one subject: stored value.
The buyer holds a balance with you that they will spend one day, and on your side that balance is a liability. Everything else in this article is one question in three variants: whose liability is it, and who covers it at the moment it gets used.
The difference between them comes down to whether the money came in:
- A gift card. The money came in. Somebody paid for the promise of goods that neither you nor anyone else has handed over yet. You have the cash and you have the debt.
- A buyer's wallet. The money either came in or arrived from a refund. A balance with a history, which the buyer treats as their own money and describes that way on the phone.
- Store credit. The money did not come in. You issued a liability of your own accord, as compensation. This is a cost, and the open question is whose.
And now the point that separates a marketplace from an ordinary store. In your own store the liability and the goods sit on the same side: you hand over your own goods and the debt disappears.
In a marketplace somebody else hands over the goods, and they have to be paid in real money. A gift card redeemed at a third-party seller is your money spent at somebody else's place.
One order paid two ways: the worked example
A cart of €1,000, one third-party seller, a commission of 12%. The seller is due €880 and you keep €120.
The buyer pays €500 with a gift card, bought from you six months earlier, and €500 with a payment card.
The payment provider collected €500 today. The seller has to receive €880.
€380 is missing and it has to leave your account. This is not a loss.
You received that money six months ago, in a different quarter, and you have probably spent it. Today it is somebody else's receivable, due in the next payout cycle.
That single subtraction is the whole content of this article. The rest is consequences.
Should a gift card be a form of payment or a discount?
The first design decision settles everything after it: the card has to work as a form of payment. The difference looks semantic.
It is financial.
If the card is a form of payment, the price stays €1,000. The seller sold for €1,000, the commission runs on €1,000, and the seller gets €880 whatever the buyer paid with.
You top up the €380, and at that moment you reduce your gift card liability by €500. The debt was paid off with goods, except that they were somebody else's.
If the card is a discount, the cart costs €500. Now a question with no good answer shows up: does the seller get €440 instead of €880?
If they do, they financed your card out of their own margin, which is not what you agreed, and your liability was never settled. It simply vanished.
In the cases we know of, this arrangement has a simple origin: the voucher was built for the operator's own store and then switched on in the marketplace without a change to the mechanics.
The operational conclusion: you calculate the commission on the price the seller sold at, whatever arrived through the payment channel. It sounds trivial until you see a system that calculates commission on what was paid in.
Then every order settled partly with a gift card quietly understates your revenue.
Who funds store credit on a marketplace?
We stay with the same order. The delivery ran a week late and support issues the buyer €100 of store credit.
The question is whose money it comes out of. Three answers make sense and you have to handle all three: the operator funds it, the seller funds it (a deduction from their settlement, because the delay was theirs), or both in an agreed proportion.
Splitting the cost of a concession between operator and seller at the level of a single order line is a market standard in this class of systems. It is worth asking about it directly.
That produces a requirement easy to miss in a demo: the deduction has to reach the seller's settlement as a separate line, attached to the order and carrying a reason. A seller who sees a payout €100 smaller and cannot say why sets off the most expensive process in a marketplace: explaining settlements by hand.
Seller trust survives a high commission and does not survive an inexplicable difference between the balance in the panel and the transfer.
Settle the commission separately. Whoever funded the €100, the seller sold for €1,000, so the commission is €120, and when the seller funds it they receive €780 instead of €880.
Compensation leaves the commission base alone, unless you deliberately decide otherwise and write that into the contract.
And there is a line you must not cross. Store credit works as an offer made to the buyer, and it cannot be your default refund policy.
EU consumer law requires a refund to go back by the same means of payment the customer used, unless the consumer expressly agrees to another. "We can offer you credit worth 10% more than the refund" is fine.
"We issue refunds as vouchers" is not. Confirm the details with a lawyer for your own country.
When does a buyer wallet become a regulated payment instrument?
A wallet starts innocently: "let overpayments and refunds land on the buyer's balance." Then somebody asks for top-ups by card, and the B2B team for budgets, limits, and budget consumption in the order they were granted. That is an account you keep for a customer.
The line runs in one place: can the buyer put money into the wallet for which they have received nothing yet. A balance fed only by refunds and compensation is a commercial liability.
A balance topped up from a card is money taken in exchange for nothing. If it can then be spent at many independent sellers, it starts to look like a payment instrument.
In the EU, there is an exclusion for instruments of limited use, so-called limited networks, and it normally covers gift cards and balances that work inside a single platform. The exclusion does not apply automatically: above a certain scale of volume you have to notify the national supervisor, who judges for themselves whether you qualify.
Outside the EU the logic can differ. In the United States some stored-value arrangements fall into state money transmission regimes.
This is a question for a lawyer before you build. The twin question about seller funds is covered by "When You Need a Payment License to Run a Marketplace?"; here it is buyers' money.
Hence a technical requirement for your vendor: a wallet balance has to be the sum of immutable entries. A field can be overwritten.
A balance assembled out of history cannot. The difference between "somebody changed a value" and "somebody appended an entry with a reason and an author" decides whether you can answer a complaint and an auditor's question.
When does tax fall due on a marketplace gift card?
With cards and a wallet the tax problem is the moment.
EU law separates vouchers whose goods and VAT rate are known at the moment of issue from all the rest. For the first kind the taxable event arises when the voucher is sold.
For the second, only when it is used. A marketplace card is redeemable at many sellers, across many categories, at different rates, and often in different countries, so almost by definition it belongs to the second group.
The consequence is a design one. At the moment a card is redeemed you have to be able to say which seller made the supply, in which country, and at which rate, and tie that back to the card sale six months earlier.
If your data model does not connect redemption to issue, that information will not appear on its own.
The second question is contractual. The seller makes the supply and you issued the card, so who is bound toward the buyer by that card, and what exactly are you selling when you sell one.
The answer decides whether your €380 top-up is the repayment of a liability or the purchase of goods. Confirm the classification and its consequences with a tax advisor.
Case law in this area is still moving.
What is breakage, and why can you not budget for it?
Some cards will never be redeemed. The phenomenon has a name: breakage.
It comes with three traps.
1. The accounting one
Revenue standards treat the payment for a card as a liability, and the part you expect to go unredeemed is recognized gradually, in proportion to the redemption of the remaining cards, rather than in one go at expiry. So there is no quarter in which a nice amount drops off the balance sheet.
2. The legal one, which depends on the country
There is no single EU rule on when vouchers expire: some member states impose minimum validity periods, and the spread between countries is wide. Sometimes unredeemed value does not stay with the issuer at all.
In cross-border selling, "our cards are valid for a year" is a claim to check country by country.
3. The planning one
Published breakage estimates scatter from low single-digit percentages up into the teens, depending on the industry and the form of the card. That spread is itself the answer: you cannot take this number from somebody else's table.
You may take a single-digit percentage as an order of magnitude, a hypothesis to verify against your own data after a year. Never as a line in a budget.
How do the 3 stored-value tools compare?
What does the setup decide? | Buyer's wallet | Store credit | Gift card |
|---|---|---|---|
Where the value comes from | a top-up or a refund | your decision | a purchase by the buyer |
Did the money come in | yes (on a top-up) | no | yes |
What it is in the books | a liability | a cost when it is granted | a liability |
Who funds it at a third-party seller | the operator | the operator, the seller or both | the operator |
Effect on the commission | none: it is a form of payment | none, as long as the price does not change | none: it is a form of payment |
Regulatory risk | high once top-ups exist | low | medium, depending on reach |
The tax moment | with the supply | with the supply | usually on redemption |
Main trap | the balance as a field, not a book | no named funder | implemented as a discount |
What does stored value decide about your marketplace?
1. The platform model settles whether you can support stored value at all
If your payment provider splits the money on their side and pays sellers directly, a payment with stored value breaks that mechanism. You cover the missing part out of your own account, which puts you back in the flow the architecture was meant to avoid.
Check in "How Do Marketplace Payments Work?" whether your model can carry it.
2. Refunds get twice as hard
Refunding our order is not "give back €1,000." It is "give back €500 to the payment card and €500 in a form you are allowed to use." Then there is what happens to the commission. "Marketplace Refunds: Who Pays for Them and Out of What?" and "Who Keeps the Marketplace Commission on a Refunded Order?" take that apart.
3. A ledger stops being optional
Three types of liability toward buyers, the flows between them, breakage, and corrections that cross a period boundary all require a book of immutable entries rather than a column with a balance ("Marketplace Ledger: Why Balances Must Match the Transfer").
4. The same question comes back with discounts and loyalty
A discount code and a loyalty point are the same funding mechanics in different packaging. Settle the funding once, properly, and you get most of the chapters on discount codes and on the loyalty program for free.
How do you settle stored value? 2 questions for you and 4 for the vendor
Two questions are for you, four for your platform vendor. Ask the vendor to show you on screen rather than answer "yes, we support that."
- Can a buyer pay in money for which they have not yet received goods? If they can, you have a regulatory question to settle with a lawyer before you start building.
- Who funds a concession, and can you actually recover it from the seller? If you cannot deduct it, every compensation is an operator cost, no matter whose fault it was.
- Is a gift card a form of payment or a discount? The answer "that depends on the implementation" means discount.
- How do you calculate the commission on an order paid partly with stored value? On a live order with two forms of payment.
- What does the store credit deduction line look like in a seller's settlement? It has to carry an amount, a reason, and a link back to the order.
- What happens when an order paid with two forms is refunded? Whether the proportions hold automatically, and whether they can be overridden with a stated reason.
With several countries or currencies a seventh question appears: are the expiry rules configurable per country, and is the balance kept per currency. One global balance in converted terms is untrue the next day.
Which mistakes do operators make about store credit and gift cards?
1. A gift card implemented as a discount
The seller quietly co-funds your promotion and the liability leaves your books without ever being settled. The hardest one to detect and the most expensive to undo, because it touches the history of every order.
2. Store credit with no named funder
Support gets the ability to hand out money that nobody assigned to any budget. You find out at the quarter close.
3. Refunds pushed onto a voucher by default
A tempting way to save cash and not allowed as a policy. The voucher has to be the buyer's choice.
4. Treating money from cards as working capital
It came in during November and it goes out in March, to somebody else. The most predictable liquidity crisis anyone can plan for themselves.
5. A buyer's balance as an editable field
The first complaint of "where are my €300" and the first audit finish that architecture off. They just make you rewrite it with production data inside.
What do you still have to settle yourself about stored value?
This is a map of mechanisms, not legal, tax, or accounting advice. Four things cannot be settled by a configuration entry:
- whether your wallet fits inside the exclusion for limited networks in your country and at your scale: a question for a lawyer who works on payment services;
- how your cards are classified for VAT and who is bound by the voucher: a question for a tax advisor;
- what the expiry rules are and what happens to unredeemed value in every country where you sell;
- how you recognize breakage: a question for an auditor, answered before anybody writes that amount into a forecast.
Our role ends where theirs begins: to show that these questions exist, and what collapses if they get asked after launch instead of before.
Summary: What does stored value actually cost you?
Cash that arrives in one quarter and leaves in another, to a third party. Settle three things before you build: a gift card as a form of payment, a named funder for every concession, and a balance assembled from immutable entries.
Everything else follows from those.
Ask a vendor to calculate the commission on a live order paid two ways, on screen. Talk to a marketplace expert if you want the six questions sharpened before the demo.
Frequently asked questions on marketplace store credit and gift cards
What is store credit on a marketplace?
Store credit is a balance you issue to a buyer as compensation, without any money coming in for it. That makes it a cost rather than deferred revenue, and the open question is whose cost.
On a marketplace it needs a named funder for each order line, because the delay that triggered it may have been the seller's.
Should a marketplace gift card be a discount or a payment?
A form of payment, always. As a payment the price stays at €1,000, the commission runs on €1,000, and the seller receives their €880 whatever the buyer paid with.
As a discount the cart costs €500, the seller funds your card out of their own margin, and your liability vanishes without ever being settled.
Can a marketplace refund a buyer with store credit?
You can offer it, and you cannot make it the policy. EU consumer law requires a refund by the same means of payment the buyer used, unless they expressly agree to something else.
Offering credit worth more than the refund is fine. Issuing refunds as vouchers by default is not.
Sources
Ready to build?
If you are planning a wallet, gift cards or store credit and want to settle who funds each of those items before they reach the backlog, let's talk.