Swag store funding models describe who pays for merchandise and how. Six work in practice: company-funded, coins or credits, employee-paid, real payments, invoice or purchase order, and hybrid role-based funding. Most mature stores combine two or three, and the right method should appear automatically based on who is logged in rather than being chosen at checkout.
The decision is not financial, it is behavioural. A coin balance and a €30 price tag can cost the company the same amount and produce completely different behaviour. Pick the model that produces the behaviour you want, then make the finance work around it.
The six swag store funding models compared
Every store Sunday builds uses one or more of these six. The design caution column is the part most buyers skip and then rebuild later.
| Funding model | Best fit | Design caution |
|---|---|---|
| Company-funded | Essential gear, onboarding kits, uniforms and workwear | Define eligibility and limits before launch. Open-ended budgets get closed abruptly, which is worse than a limit |
| Coins or credits | Rewards, recognition and anniversaries | Explain what a coin is worth, and seed balances at launch so nobody sees an empty wallet |
| Employee-paid | Optional extras, after a funded baseline exists | Never launch a store as pure profit. Paid-only reads as the employer selling to staff |
| Real payments | Internal e-commerce and public or fan stores | Currency, tax and refund handling are day-one decisions, not later configuration |
| Invoice or purchase order | Managers, departments, franchises, enterprise buyers | Validate the role and capture references correctly, or finance rejects the invoice weeks later |
| Hybrid, role-based | Mixed audiences sharing one storefront | The right method should appear automatically. Asking users to pick is a design failure |
How each model works in practice
Company-funded
The company pays, the employee receives. This is the right model for anything that is genuinely a work requirement or a welcome: onboarding kits, essential gear, uniforms and branded workwear. The design work is not the payment, it is eligibility. Who qualifies, how often, and up to what value. Get that written down before launch and the store never has to say no awkwardly. The wardrobe version of this model is covered in the corporate clothing brand store guide.
Coins and credits
A company-funded balance that employees spend on merchandise instead of cash. It is the strongest model for rewards and recognition, because a balance can be granted at a moment and spent at leisure. Fastned allocates coins automatically on first login and can add more at any point, so the first visit to the store is a gift rather than a shop. Interstellar runs the same mechanic in a store denominated in its own coin currency.
Employee-paid
Employees buy with their own money. This works, but only as a second layer. Once a funded baseline exists, optional paid extras feel like access to a good internal shop. Launched alone, the same store reads as the employer profiting from staff, and adoption never recovers. The full argument is in the online swag store for employees guide.
Real payments
Card payments, multiple currencies, real refunds. Necessary for public and fan stores, and useful for internal stores where employees genuinely buy. BVNK runs internal e-commerce with real payments across multiple currencies, which is the practical proof that multi-currency is a capability to deploy rather than an obstacle to design around. The decisions to make on day one are which currencies you present, how tax is handled per destination, and what your refund policy actually is.
Thule combines SSO with a coin balance for managers ordering on behalf of their teams, plus custom order emails and client-editable store content.
Invoice or purchase order
The manager, department or enterprise model. Instead of paying at checkout, the buyer places an order against a purchase order and finance settles later. It is the least glamorous model and the one that saves the most administrative time when it is built properly. Zalando House of Merch captures purchase-order references correctly at checkout and applies volume-based dynamic pricing tied to minimum order quantities, so team orders price themselves without a quote request.
The failure mode is always the same: a purchase order captured loosely, then an invoice that finance cannot match. Validate the role, require the reference, and make the field impossible to skip.
Hybrid, role-based
One storefront, several funding methods, selected by who is logged in. ITI's store selects Stripe or invoice dynamically depending on the user's role, so an individual member checks out with a card while an institutional buyer checks out against an invoice. Neither group sees the other's flow. The store is built for an expected 35,000 to 40,000 users a year, which is a design target rather than a reported result, and at that scale manual routing is not an option.
Zalando House of Merch: brand-approved UI, SSO gating, purchase-order controls and minimum-order-quantity pricing that adjusts as team orders scale.
Why hybrid role-based funding usually wins
Most real programmes have more than one audience. Employees redeem coins. Managers order against a purchase order. Partners buy at a set price. Customers pay full price. Trying to serve all of them with a single funding model forces three of the four into a flow that does not fit.
Hybrid funding solves it by attaching the method to the role rather than to the store. Identity does the work: the user signs in, the store knows who they are, and the correct prices, products and payment method appear. Nobody chooses a checkout type, because choosing a checkout type is not a thing shoppers should have to do.
This is also where funding stops being a finance question and becomes an integrations question. Identity providers, HRIS credits, procurement systems and payment providers all feed the same checkout. That plumbing is covered in swag store integrations.
Designing a useful coin system
Coins go wrong when they are treated as gamification. Points for logging in, badges, streaks, leaderboards. Employees see through it quickly, because the reward is not connected to anything real.
A coin system earns its place when balances are tied to moments that already matter. The question to start from is not how many coins someone should get. It is what behaviour or moment should this balance enable. Answer that and the amounts become obvious.
The moments that consistently justify a credit:
- Onboarding. A balance on day one turns a store into a welcome.
- Work anniversaries. Predictable, date-driven, easy to automate. See work anniversary gifts.
- Birthdays. Low cost, high goodwill, no performance judgement attached.
- Recognition. Peer or manager nominations, where a human decision is the point.
- Referrals. A credit that arrives when a referred candidate is hired.
- Training and certification. Completion of something the company asked for.
- Wellness participation. Programmes people opt into rather than are measured on.
- Sales and team achievement. Where merchandise beats a cash bonus for memorability.
Two practical rules. First, publish the value of a coin somewhere obvious, because an unexplained balance creates hesitation and hesitation kills casual use. Second, seed balances at launch. A coin store that opens with everyone at zero is an employee-paid store wearing a costume.
Interstellar's checkout prices the whole order in coins, with delivery to a chosen office. When the balance is the currency, the transaction never feels like a purchase.
Manual or automated allocation
Both are right, for different moments.
| Manual allocation | HRIS-automated allocation | |
|---|---|---|
| Best for | Recognition, exceptional moments, one-off thanks | Lifecycle events: onboarding, anniversaries, birthdays |
| Why it works | A human decided, and the recipient knows it | It never gets forgotten, at any headcount |
| Watch out for | It stops happening when people get busy | It can feel automatic, because it is |
Bitpanda Boutique runs credits through the Workday API, so lifecycle allocations happen without anyone maintaining a spreadsheet, and new products get tagged automatically so returning employees can see what changed. Most mature programmes run both routes at once: automation carries the calendar, humans carry the recognition. That split mirrors the wider principle that automation should remove administration, not humanity.
The funding mistakes that cost adoption
- Launching paid-only. The store gets categorised as a shop, permanently.
- An unexplained coin value. People will not spend a currency they cannot price.
- Zero balances at launch. Technically a coin store, functionally an employee-paid one.
- Eligibility decided after go-live. Every exception then becomes a negotiation.
- Loose purchase-order capture. Finance rejects the invoice, and the store gets blamed.
- Making users choose a payment method. Role-based routing exists for a reason.
- Treating funding as the whole strategy. Funding shapes behaviour, but a static store still dies.
Funding is one decision in a larger operating model. The store still needs curation, stock, fulfilment and a reason to return, all of which sit in the company swag store hub. And whichever model you pick, judge it on the programme outcome rather than the revenue it produced, using the framework in swag store metrics.
To see how Sunday configures funding, access and fulfilment together, explore the platform, the catalog and how it works.
About this article
Funding that fits the audience
Coins, credits, card payments, invoices and purchase orders in one storefront, routed automatically by role. Create a free account and configure yours.
Build your swag store
