Global reward coverage is easy to overstate. A vendor may describe a worldwide program while its public catalog, settlement currency, delivery method, and product terms vary by account and market. This 2026 dataset gives procurement, finance, product, engineering, and program owners a repeatable way to separate documented coverage from assumptions before they promise a recipient experience.
What this dataset proves—and what it deliberately leaves unknown
Version 2026.09.11-v1.0 is a public-evidence sample covering five providers and four markets: the United States, Taiwan, Japan, and South Korea. It contains twenty stable provider-market rows plus a restriction register, source manifest, change log, field dictionary, and quality checks. It does not reproduce a provider's authenticated live catalog, claim exhaustive global reach, or turn a marketing statement into product-level availability.
The central rule is simple: “confirmed” means an official public page explicitly names the market or capability cited in the row. “Not confirmed” means the reviewed page did not establish that provider-country-reward combination. It does not mean unavailable. “Unknown” is not a weak answer; it is a procurement task. It tells the owner exactly which fact must be confirmed through a current catalog response, contract, product terms, or provider representative before launch.
The sample is intentionally conservative. Giftbit publishes a countries page and delivery-method guidance, while Tango exposes a public catalog with country filters. Tremendous and Runa document catalog APIs, but a general global claim or endpoint description does not prove every country-product pair. Giftpack is included as an execution-layer option, but public catalog details that could not be verified during this run remain unknown rather than being inferred.
This discipline matters because “country supported” can refer to several different things. It may mean a sender can fund an order, a recipient can receive a link, a specific merchant card can be redeemed, a prepaid product is permitted, or support is available in a language. Those are not interchangeable. A program can technically send a link to a country and still fail the buyer's actual requirement because the desired currency, denomination, mobile experience, or refund rule is absent.
The workbook therefore preserves separate fields for country code, display country, currency, reward type, delivery channel, recipient choice, denomination bounds, expiration disclosure, cancellation disclosure, identity and address requirements, business availability, source date, verification date, confidence, and notes. This structure makes gaps visible instead of hiding them inside a single “coverage” column.
Treat every unknown as an assigned verification step, not as permission to assume availability.
Download the localized evidence files
The XLSX edition contains seven sheets: Read Me, Field Dictionary, Coverage, Restrictions, Source Manifest, Change Log, and QA. The CSV edition contains the same twenty coverage rows in a portable UTF-8 format. Both files use stable row identifiers so a later release can show exactly which provider-market record changed.
The files are designed for evidence review, not vendor ranking. Filters let a buyer isolate a provider, market, evidence state, or confidence level. The Restrictions sheet converts material gaps into operating responses. The Source Manifest records the official page used for each evidence family. The QA sheet contains row-count and required-field formulas, while the production record separately verifies duplicate keys, HTTPS protocols, formulas, archive integrity, and every rendered worksheet.
How to interpret the download when a field says “Unknown”
First, preserve the unknown value in your working copy. Second, assign the field to an owner: procurement for contractual availability, engineering for catalog responses and delivery methods, finance for funding and settlement, privacy or compliance for identity requirements, and the program owner for recipient experience. Third, attach the dated answer and its source. Do not replace unknown with a national currency or a common delivery pattern merely because it seems likely.
The version date is part of the evidence. Catalogs and product terms change, so a workbook downloaded today should not be treated as permanent entitlement. The recommended refresh is quarterly, with an additional review after a provider announces a catalog expansion, payout change, card-program change, regulatory restriction, or API-version change.
A usable representative slice
The table below is a compact article view of the downloadable dataset. It shows evidence state, not a complete product inventory. Currency and product-level terms remain unknown where the official public page did not provide a verifiable pairing.
| Stable row ID | Provider | Market | Public evidence state | Documented delivery path | Operational note |
| giftbit-us-digital-catalog-v1 | Giftbit | United States | Confirmed from public countries page | Email, link, in-app | Query the account catalog for product currency and denominations |
| giftbit-tw-digital-catalog-v1 | Giftbit | Taiwan | Not confirmed by page reviewed | Email, link, in-app capability documented generally | Do not infer Taiwan availability from broader regional language |
| giftbit-jp-digital-catalog-v1 | Giftbit | Japan | Confirmed from public countries page | Email, link, in-app | Verify Japanese catalog, claim terms, and recipient instructions |
| giftbit-kr-digital-catalog-v1 | Giftbit | South Korea | Confirmed from public countries page | Email, link, in-app | Verify Korean catalog, mobile flow, and product restrictions |
| tango-tw-digital-catalog-v1 | Tango | Taiwan | Confirmed in public country filter | Email and choice-link capabilities documented | Re-query product-level availability and local currency before order |
| tremendous-jp-digital-catalog-v1 | Tremendous | Japan | Market-product pairing not proven publicly | Email, link, and SMS documented | Use the current products endpoint for the production account |
| runa-kr-digital-catalog-v1 | Runa | South Korea | Market-product pairing not proven publicly | API and payout-link workflow documented | Retrieve current catalog and retain the response fingerprint |
| giftpack-us-digital-catalog-v1 | Giftpack | United States | Public catalog detail not verified in this review | Execution workflow requires confirmation | Confirm scope during implementation rather than assigning a score |
The ordering is provider name followed by market code; it is not a recommendation order. The confidence field rates the evidence attached to a row, not the quality of the provider. “High” means the official public page explicitly supports the narrow statement. “Medium” means the provider documents the capability or catalog mechanism, but the market-product pairing still needs account-level evidence.
This distinction prevents a common comparison error. A public country list may prove that a provider serves Japan, but it does not prove that a particular Amazon Japan denomination is available to a newly approved account, that the product has no claim deadline, or that cancellation is possible after issuance. Those facts belong in separate fields with separate evidence.
Methodology: from official page to stable row
The research process starts with a buyer requirement, not a vendor claim. Define the recipient country, preferred currency, acceptable reward families, delivery channels, recipient-choice requirement, denomination range, timing, identity-data tolerance, and cancellation expectation. Without that specification, a large catalog count cannot tell you whether the program will work.
Next, collect only official evidence. Public product catalogs, developer documentation, terms, help centers, and current provider country pages qualify. Search-result snippets, affiliate directories, crowd-sourced lists, and review sites do not. Each source must use HTTPS and be live on the verification date. When a page provides a general capability but not a country-product pair, the dataset records the capability and leaves the pair unconfirmed.
Normalize carefully. Country and territory identifiers use ISO 3166-1 alpha-2 codes so systems can join the data, but the workbook also preserves a localized display name. Currency uses ISO 4217 only when the provider evidence or authenticated catalog supports the relationship; the national currency is not automatically substituted. Provider wording is preserved in notes when its definition differs from the normalized field.
Each row identifier combines provider, market, reward family, and version-independent semantics. It stays stable when a source date or note changes. A new identifier is required only when the business object changes, such as splitting one generic digital-catalog row into separate prepaid-card and merchant-card rows. Stable keys support revision logs, joins, and automated diff checks.
Quality checks cover seven failure classes: blank stable keys, duplicate stable keys, missing required fields, non-HTTPS sources, invalid enumerations, orphan restriction references, and broken formulas. Every worksheet is also rendered because a valid file can still be unusable when headings clip, filters obscure fields, or CJK glyphs render as empty boxes. The localized workbooks use CJK-capable fonts and were visually reviewed sheet by sheet.
The method intentionally separates public evidence from authenticated evidence. A production catalog response should be saved with request context, account, environment, timestamp, API version, and a cryptographic fingerprint where policy permits. That response can upgrade a market-product row, but it should not silently overwrite what the public page proved. Keeping both layers allows reviewers to distinguish externally reproducible claims from account-specific entitlement.
Acceptance evidence for a refreshed release includes the source manifest, row-diff report, zero duplicate keys, zero missing required URLs, zero non-HTTPS URLs, successful formula scan, openable XLSX archives, readable UTF-8 CSV files, rendered worksheets, file byte counts, SHA-256 checksums, and immutable download receipts. A release is not complete merely because a spreadsheet was generated.
How teams should turn the dataset into a launch decision
Start with a requirements table owned by the program lead. One row should represent one recipient segment, such as employees in Japan receiving a year-end recognition award, or research participants in South Korea receiving a small digital incentive. Record the planned volume, value range, sending entity, funding currency, delivery window, desired choice, fallback reward, and personal data available.
Procurement then joins those requirements to the coverage dataset. A confirmed market row is only the first filter. The reviewer must still obtain product-level denominations, commercial terms, refund rules, account eligibility, support model, and service commitments. Finance confirms funding method, foreign-exchange treatment, invoicing, reconciliation fields, and liability for unclaimed value. Legal, tax, privacy, and payroll owners decide the applicable policy; this dataset does not replace those decisions.
Engineering retrieves the current catalog in the intended production environment. Store the raw response, a normalized extract, and the request metadata. Compare the response to the approved requirements. Do not let a sandbox result stand in for production: providers can expose different products, limits, or test data. Confirm that retries are idempotent and that delivery outcomes can be reconciled without issuing a second reward.
The program owner tests the recipient experience in the actual language and device context. Email deliverability, mobile redemption, country selection, value display, product terms, and support instructions must all be understandable. A technically valid link can still be a failed experience if the recipient cannot identify the sender, sees an unexpected currency, or encounters a product restriction only after making a choice.
Use explicit gates. A market is ready only when the catalog snapshot contains an approved product, the value fits the required range, the delivery method is tested, required recipient data is approved, terms are reviewed, funding is available, and a documented fallback exists. Keep “partially ready” separate from ready; otherwise an unresolved denomination or identity field can disappear inside an optimistic status.
Operational monitoring continues after launch. Track accepted orders, claim or redemption, delivery failure, cancellation, support contact, and reconciliation exceptions by market and provider. A coverage dataset is useful when it supports decisions over time, not when it becomes a static procurement appendix.
A concrete execution path
-
Program owner defines the four-market requirement and fallback for each segment.
-
Procurement records public and contractual evidence without merging them.
-
Engineering captures the authenticated production catalog and fingerprints the response.
-
Finance confirms funding, settlement, reconciliation, and value limits.
-
Privacy, legal, tax, or payroll owners review the fields within their authority.
-
Local reviewers complete recipient-experience tests in English, Traditional Chinese, Japanese, and Korean.
-
The release owner compares stable row IDs, records changes, and publishes a new dated version.
The acceptance packet should let a reviewer answer five questions without a meeting: what requirement was tested, which official source supported it, which production response proved current entitlement, who accepted the remaining restrictions, what fallback activates when delivery fails, and when the evidence expires for review purposes.
Hypothetical worked case 1: Japan employee recognition
Assume a company wants to recognize 240 employees in Japan with recipient choice and values between JPY 5,000 and JPY 10,000. The People team prefers email delivery, finance funds from a US entity, and privacy wants to avoid collecting home addresses. This is a hypothetical planning case, not Giftpack customer evidence.
The first pass should not ask, “Which vendor is global?” It should ask whether the production account exposes Japan products in JPY within the value range, whether a choice experience is available, whether email is supported, what recipient fields are required, and what happens to an unclaimed or failed reward. The public sample can identify providers with documented country coverage or catalog mechanisms, but it cannot finish the decision.
Suppose one provider's public page names Japan but leaves currency and denominations unknown. Procurement marks the market row as provisionally eligible. Engineering then queries the production catalog. If the response includes several Japan products but only fixed JPY 3,000 and JPY 5,000 denominations, the program can choose one of three paths: narrow the award to JPY 5,000, find a variable-value product, or retain another provider for higher-value awards. Each alternative changes budget consistency and operational complexity.
Now assume the preferred product requires only recipient email, while a prepaid alternative asks for additional identity information during redemption. Privacy can approve the first path for a recognition program with minimal data. The prepaid path may still be valid, but it needs a distinct notice, retention decision, and support plan. The dataset should not collapse both products into one “Japan supported” answer.
If an email delivery test fails because a corporate filter blocks the provider domain, the recovery path is not to create a second order immediately. Confirm order status, regenerate or obtain a secure delivery link if supported, send it through an approved internal channel, and retain the same reward record. Acceptance requires one successful Japanese mobile redemption test, correct JPY display, accessible terms, sender recognition, and reconciliation back to the stable event ID.
This case shows why unknown values are useful. They concentrate work on the exact facts that can change the launch decision rather than encouraging a broad, unsupported platform score.
Hypothetical worked case 2: South Korea research incentives
Assume a research team plans 1,500 small incentives for verified participants in South Korea. The intended value is KRW 10,000, the survey platform can deliver a unique link, and the study needs a fast turnaround. Fraud controls matter because duplicate participation would distort both budget and research quality. This is also a hypothetical case.
The buyer should separate catalog coverage from program eligibility. A provider may offer South Korea products but prohibit some program categories, require business verification, or expect the sender to operate participant safeguards. Procurement reviews allowed use, finance confirms funding and transaction limits, research operations defines one reward per verified participant, and engineering makes the study event ID the idempotency key.
If the public page confirms South Korea but does not disclose a KRW product, the team queries the authenticated catalog. A result in another currency may be technically deliverable yet unsuitable because it shifts conversion or redemption uncertainty to the participant. The team should prefer a local-currency product when the evidence supports it, or disclose the alternative and obtain approval rather than labeling the row KRW by assumption.
Delivery choice has a real tradeoff. Provider-sent email may reduce implementation effort and support resends, while a link returned to the research system gives the study more control over timing and identity matching. Link delivery also places more responsibility on the buyer for secure storage, access logging, and preventing the same participant from claiming multiple rewards. The correct choice depends on the study's data flow, not a generic feature ranking.
Suppose the catalog removes the selected product midway through fieldwork. Recovery starts by pausing new issuance for the affected market, preserving accepted orders, and retrieving a fresh catalog. The owner selects an approved fallback with equivalent value, updates participant language, records the row change under a new dataset version, and tests one controlled redemption before resuming. Existing rewards are not replaced until their actual status and provider rules are known.
Acceptance evidence includes a current catalog fingerprint, allowed-use confirmation, KRW value verification, one successful mobile claim, one duplicate-event test that does not issue twice, a documented pause-and-fallback procedure, and finance reconciliation from study event to provider order. Those controls are more informative than a simple “South Korea: yes.”
Failure modes, recovery paths, and refresh ownership
The most common failure is silent inference. A buyer sees “150+ countries” and fills national currencies, delivery channels, or product types without evidence. Recovery requires reverting inferred values to unknown, identifying the claim source, and querying the current catalog for each required pairing. The correction should appear in the change log so downstream users know why a previously populated field disappeared.
Stale evidence is the second failure. A source page may remain live while the underlying product list changes. Assign a next-review date and treat material provider notices, API deprecations, card-program changes, or repeated order failures as early refresh triggers. A quarterly cadence is a floor, not a guarantee that data remains current for ninety days.
A third failure is confusing account entitlement with public availability. Production access, funding method, risk review, business location, and contract tier may affect what the account can order. Store account-specific evidence separately, label the environment, and avoid publishing private catalog details that the provider does not make public. Public article claims should remain reproducible from official public sources.
A fourth failure is treating technical acceptance as recipient success. An accepted API request may still be queued, rejected later, undelivered, unclaimed, or incompatible with the recipient's device. Define statuses that distinguish request accepted, reward issued, delivered, claimed, redeemed, canceled, and reconciled. Each status needs an owner and a time-based exception rule.
A fifth failure is updating the workbook without preserving stable keys or checksums. That breaks joins and makes it impossible to tell whether a file changed. Every release must retain stable row IDs, increment the version, regenerate localized files from the same normalized evidence, render all sheets, and record byte size and SHA-256. The prior version should remain archived rather than overwritten.
Ownership works best when explicit. The program owner defines experience and fallback; procurement owns provider and contract evidence; engineering owns catalog retrieval and delivery integration; finance owns funding and reconciliation; privacy and compliance own data and policy reviews; local reviewers own language and usability; and the release owner owns versioning, checksums, and publication evidence. A RACI table is only helpful if each unknown field has a named resolver and due date.
When should a row be upgraded from “not confirmed” to “confirmed”?
Upgrade it only when new official public evidence explicitly supports the same provider-market-reward statement. Authenticated account evidence can create a separate internal confirmation, but it should not be represented as publicly reproducible. Record the source, date, exact statement, reviewer, and new file fingerprint. If evidence later disappears, keep the historical record and mark the current public state accordingly.
A defensible coverage decision is more valuable than a large country count
Global digital rewards are an operating system of catalogs, funding, recipient data, delivery, terms, and support. A single reach number cannot represent that system. The practical goal is to build a chain of evidence from buyer requirement to market row, current product, tested recipient experience, and reconciled outcome.
Use this version as a starting structure. Keep confirmed claims narrow, keep unknowns visible, and preserve the difference between public documentation and production-account evidence. Before every material campaign, retrieve the live catalog again and recheck value, delivery, identity, expiration, and fallback requirements. For tax questions, use the Global Employee Gift Tax Dataset; for governance, use the Global Corporate Gift Compliance Hub; and for cost modeling, use the Corporate Gifting Platform Pricing Guide.
When a team needs to execute the approved decision across countries, Giftpack can serve as the gifting execution layer for catalog coordination, recipient choice, delivery operations, and exception handling. It does not replace procurement, tax, legal, payroll, privacy, or employer decisions; the evidence owners remain accountable for those gates.