Skip to content

Use cases

Design the customer journey.
Then choose the integration.

A voucher reward, a player top-up and a travel data plan solve different customer needs. These planning scenarios help you define the recipient experience and the work your team must own.

01 / Rewards and loyalty

Make the reward usable,
not just deliverable.

For teams evaluating employee, customer or membership incentives.

  • Recipient decision

    Choose a reward that fits the recipient’s redemption market and currency. Define the information they see before accepting it.

  • Your team owns

    Campaign eligibility, recipient communication and the first support conversation. Make redemption instructions accessible after delivery.

  • Exception to plan

    A recipient cannot redeem the code. Capture the product, market and error context through a safe support channel; do not ask them to expose a usable code publicly.

Illustrative planning example

A reward is sent to someone in another market.

Successful code delivery does not establish that the recipient can redeem it. Resolve the market requirement before selecting a product, and define who handles a mismatch.

Gift card integration requirements

02 / Digital commerce

Treat fulfilment as part
of your customer promise.

For marketplaces, resellers and products evaluating a digital-goods category.

  • Customer decision

    Show the relevant product restrictions before purchase: denomination, region, platform or recipient details depend on the category.

  • Your team owns

    Product presentation, customer communication, the support path and the decisions in your own checkout.

  • Exception to plan

    A request has an uncertain outcome. Keep the customer informed while your team reconciles the result; a blind repeat can create a second commercial action.

Illustrative planning example

One storefront, different fulfilment paths.

A code that must be redeemed and a credit applied to an account need different confirmation screens. Choose a workflow per category instead of hiding both behind a generic “delivered” message.

Compare product-category requirements

03 / Gaming distribution

Confirm the player
or the platform first.

For gaming-focused teams comparing direct credits with redeemable game keys.

  • Direct top-up journey

    Collect and confirm the applicable player and server identifiers before the customer commits. Define the correction path for a mistyped identifier.

  • Game-key journey

    Explain the platform, edition and activation-region requirements before code delivery. Keep usable keys out of routine logs.

  • Exception to plan

    Separate “credit not visible” from “key cannot activate”. They need different evidence, support ownership and customer instructions.

Illustrative planning example

A game name is not a sufficient product identifier.

The same title can have different editions or platform restrictions. A player-credit product introduces a different question: which account and server should receive it?

Player top-up planning Game-key activation planning

04 / Mobile and travel

Help the customer choose
what will actually work.

For wallet, telecom and travel products evaluating recharge or connectivity.

  • Recharge journey

    Distinguish airtime from a bundle and confirm the intended number and operator where required. Explain whether the purchaser and recipient are different people.

  • eSIM journey

    Check destination requirements and device compatibility before selection. Explain the difference between installing a profile and activating plan validity.

  • Exception to plan

    A traveller may need help without a working connection. Provide setup instructions and the support path before departure.

Illustrative planning example

A traveller purchases before leaving home.

Buying a plan, downloading its profile and starting its validity are separate events. Confirm the applicable activation conditions before promising when service begins.

Recharge planning eSIM compatibility and activation

Bring one defined scenario

Turn the use case into a reviewable brief.

Choose a first journey. An explicit boundary is more useful than a list of every possible future category.

  1. 01

    Describe the recipient

    Who receives the product, in which intended market, and what outcome do they expect?

  2. 02

    Assign the decisions

    Who selects the product, confirms the details, communicates progress and handles a problem?

  3. 03

    State the starting scope

    Name the initial category, expected volume range and the questions your team needs answered before integration.

Have a journey with a clear business owner?

Introduce your company, chosen categories and expected volume. Use the follow-up conversation to discuss the scenario and responsibilities.

Submitting a request does not create an account or guarantee approval.

Request API Access