To compare gift card APIs, ask every provider the same twelve questions about catalogue coverage, ordering safety, delivery, funding, testing and support, and judge them on the answers rather than on the demo. The happy path looks alike everywhere; providers differ in what happens on timeouts, partial failures and price changes, and those differences only show up when you ask.
Switching providers after integration is expensive: product mappings, order flows and reconciliation all get rebuilt. An hour spent on these questions before the first line of code is the cheapest insurance in the project. For the company-level checks (registry, provenance, replacement policy), see how to vet a gift card supplier; this list is the technical and operational half.
Catalogue
1. Which brands and regions can I actually sell, today? Ask for a catalogue export filtered to your target regions, not a logo wall. A brand listed globally may be available in only a few countries.
2. How are price and availability updated? You want live or near-live availability per product, and a documented way to detect changes. A catalogue refreshed once a day can sell you items that went out of stock hours ago. Our catalogue API guide lists the fields to look for.
3. Are product IDs stable? If IDs change on refresh, every mapping you build breaks. Ask directly and get the answer in writing.
Ordering
4. Does the order endpoint accept an idempotency key? This is the single most important technical question. Without one, a retried timeout can buy the same code twice, as explained in idempotency for gift card orders.
5. Is ordering synchronous, asynchronous, or both? Most orders complete in seconds, but some queue. Ask what the response looks like when an order is pending and how long pending can last.
6. Is there a batch endpoint, and what are the rate limits? Volume buyers need documented limits and burst rules, not “we have never had a problem”.
Delivery
7. How are results delivered: webhooks, polling, or both? The robust answer is both, so you can run webhooks as the fast path and polling as the sweep. Ask whether webhooks are signed and how retries work.
8. Can a delivered code be fetched again? If an email bounces, you need to re-deliver without re-buying. A re-fetch endpoint, scoped and logged, saves a support ticket every time.
Money
9. How is the account funded, and in which currencies? Most providers work on prepaid balance. Ask about top-up rails, settlement currency and low-balance alerts; sizing a prepaid deposit covers the risk side.
10. What statements do I get? You need a per-order statement you can match line by line against your own records, ideally downloadable through the API.
Testing and support
11. Is there a sandbox that simulates failures? A sandbox that only returns success tests nothing. Ask whether you can trigger timeouts, out-of-stock and pending states on demand.
12. Who answers when something breaks? Ask for the escalation path, response expectations and the process for already-redeemed code reports. A named technical contact beats a generic ticket form.
Reading the answers
| Question area | A good answer sounds like | A red flag sounds like |
|---|---|---|
| Catalogue coverage | “Here is the export for your regions” | “We have everything” |
| Price updates | “Live per product, with change timestamps” | “We update the list daily” |
| Idempotency | “Send a key; repeats return the original order” | “Just do not retry” |
| Pending orders | “Documented status and expected window” | “Orders never queue” |
| Webhooks | “Signed, retried, with a polling fallback” | “Webhooks only, unsigned” |
| Funding | “Prepaid balance, alerts, clear statements” | “Payment to personal accounts, no statements” |
| Sandbox | “Failure modes on demand” | “Use production with small orders” |
| Support | “Named contact and written dispute process” | “Email us if something happens” |
No provider will score perfectly on all twelve. The point is to know where the gaps are before you depend on them, and to decide which ones you can engineer around.
Run the same test against each shortlisted API
Answers are claims; a sandbox session is evidence. For each provider on your shortlist, run one identical script:
- Pull the catalogue for one region and check the fields against your needs.
- Place an order, then repeat it with the same idempotency key.
- Force a timeout or pending state and recover it through status lookup.
- Receive a webhook, verify its signature, and replay it to confirm deduplication.
- Download the statement and match it to your test orders.
The full drill is in testing a gift card API sandbox. Teams that run it on two or three providers usually find the decision makes itself.
If Giftoro is on your list: we work with businesses only, cover catalogue, pricing and instant code delivery through one integration, and onboarding includes KYB and a test order in about 1.5 hours. The gift card API page has the overview.
Frequently asked questions
What is the most important question when comparing gift card APIs?
Whether the order endpoint supports idempotency keys. Codes are not returnable once delivered, so an API that cannot safely absorb a retried request turns every network timeout into a potential duplicate purchase. Everything else can be worked around more easily than that.
Should I integrate more than one gift card API?
Some larger sellers do, to widen coverage or keep a fallback for popular products. It doubles the mapping, funding and reconciliation work, so start with one provider and add a second only when a specific gap justifies it.
How long does it take to evaluate a gift card API?
The questions take an hour per provider; a meaningful sandbox test takes a day or two of engineering time. Business onboarding can run in parallel, so a full evaluation of two or three providers often fits inside a couple of weeks.
Is a bigger catalogue always better?
No. What matters is coverage of the brands and regions your customers buy, with reliable stock. A smaller catalogue that is always in stock for your top products often beats a larger one with gaps where it counts.
What documentation should a gift card API provider share?
At minimum: an endpoint specification, error codes with retry guidance, webhook format and signing method, rate limits, and sandbox credentials. If the provider cannot share these before a contract, treat that as part of the answer.