Stablecoin payments at an OTA

The Pilot

Vendor selection, regulatory work, and launching a controlled pilot — customer-side and supplier-side in parallel

What this part covers

Part 1 established the case for stablecoin payments at an OTA, the regulatory landscape, and the internal diagnostic to decide whether to proceed. This document picks up where that ended and covers two phases:

• Phase 1 - Regulatory and vendor assessment (typically one quarter). Four parallel workstreams: country-level legal review, gateway selection, custody and accounting architecture, pilot market choice. The output is a signed contract, an approved market, and an integration plan.
• Phase 2 - Pilot launch (typically the following quarter to build, then a live run). One market, one gateway, two stablecoins. A customer-side pilot at checkout, plus a parallel supplier-payment pilot in a fragmented inventory market. The output is data: does adoption ramp, do the economics work as modelled, and is the operational load sustainable?

Part 3 covers what to do once the pilot is producing data: how to scale, the full risk register, and the final go/no-go recommendation.

4. Phase 1 - Regulatory and vendor assessment

Duration: 8–12 weeks | Owner: Head of Payments, with General Counsel, Treasurer, Information Security | Outcome: selected gateway, approved pilot market, signed contract, integration plan

Indicative cost: this phase is mostly internal time plus external legal fees. Budget for counsel across the candidate markets (the largest external line) and any advisory support on vendor selection. No platform or build cost is committed until the term sheet is signed at the end of the phase. Phase 1 is deliberately structured so the spend that matters comes after the regulatory and commercial gates, not before.

4.1 Run four workstreams in parallel

Running these one at a time adds roughly a quarter or two to the timeline. They are independent enough to run simultaneously, and running them serially mainly delays the point at which you can see whether the regulatory and commercial cases hold together.

4.2 Choose the acceptance model first. It decides who carries the KYC

Before evaluating any vendor, settle one structural question, because it shapes everything downstream: end-customer friction, your finance team's workload, and which gateways even fit. The question is whose customer the payer is, and therefore who owns identity verification (KYC on individuals, KYB on businesses). There are two models, and they are not interchangeable.

Model A - Invoice in stablecoin; the gateway provides a merchant wallet

The OTA prices and invoices the booking in stablecoin, and the gateway provisions a merchant wallet that receives the customer's payment. The customer is simply sending a stablecoin payment to a merchant, so identity obligations on the payer are limited to what any third-party payment requires, not the full KYC of a regulated service being sold to them. In some arrangements the merchant holds the wallet keys directly, which reduces the obligation further. Stablecoins can still be converted to fiat afterwards, but in this model the conversion is done for the merchant, as the gateway's customer, not for the payer.

• Upside: materially lower friction at checkout. The customer is not pushed through an identity-verification flow to make a booking.
• Downside: higher finance lift. Pricing or invoicing in stablecoin, holding a merchant wallet, and managing the conversion and reconciliation all sit with your team rather than being abstracted away.

Model B - Invoice in fiat; the gateway is a ramp converting on the payer's behalf

The OTA prices and invoices in fiat as it does today. The gateway accepts stablecoin from the customer, converts it to fiat, and pays the OTA in fiat. The important nuance: here the gateway is acting as a ramp, converting stablecoin to fiat on behalf of the payer. That is a regulated service provided to the customer, which triggers full KYC on the payer.

• Upside: far easier for an existing fiat-native ('web2') merchant to implement. Nothing changes in your pricing or accounting: fiat in, fiat out.
• Downside: much higher end-customer friction. The customer must complete identity verification to pay, which is a heavy ask for a routine booking.

This model question applies to the customer-facing track. The supplier-payment track in section 5.4 is a separate flow. You are the payer there, paying known, onboarded suppliers, so the identity obligations sit with you as the originator and are screened as part of supplier onboarding.

4.3 The vendor landscape - what to evaluate

Once the acceptance model is chosen, there are four broad types of counterparties an OTA should consider. They are not mutually exclusive - most production setups use a checkout gateway plus a treasury/custody platform. For the pilot, only the first two are in scope. Note that not every gateway supports both models above; confirm model fit before going deep on commercial terms.

4.4 What to ask gateway vendors

Most stablecoin gateway sales material reads identically. The differences show up in commercial terms and operational specifics. A short request-for-proposal built around the questions below will force those into writing.

Commercial - the terms that quietly erode the case if you don't ask

• All-in transaction fee, broken into: gateway fee, conversion (FX) fee, network fee pass-through, and settlement fee.
• FX rate methodology - which reference rate is used, what spread is applied, with a worked example for the corridor that matters most to you.
• Volume-tier discount schedule with concrete breakpoints.
• Refund handling - when a refund flows back through the gateway, who carries the FX risk between original payment and refund execution.

Operational - what happens when something goes wrong

• Supported networks and tokens, with average confirmation times by network.
• How the gateway notifies your systems of completed payments; what happens if a notification is missed or duplicated.
• Reconciliation file format and cadence; mapping into your ledger or ERP.
• Service level agreements (SLAs), incident communication protocol, and named operational contacts.

Compliance - where the regulatory load sits

• Which acceptance model the gateway supports (per 4.2) - invoice-in-stablecoin with a merchant wallet, invoice-in-fiat with the gateway as ramp, or both - and, for the ramp model, whether a KYC-reliance arrangement is available.
• Current licenses (MAS PSA, FCA authorization, MiCA registration, US state money transmitter licenses). Which expire when, and which applications are pending.
• Sanctions and AML approach: which screening provider is used, how often the lists update, the policy on partial matches, and how the gateway escalates to you.
• Travel Rule support.
• Data residency, sub-processors, and audit reports (SOC2 Type II, ISO27001).
• Are merchant balances bankruptcy-remote if the gateway fails? What is the legal mechanism?

References

• Two reference customers in travel or e-commerce at meaningful volume — a direct conversation, not a logo wall. A question worth asking each: when something went wrong, how did the gateway respond?

4.5 Choosing the pilot market

The Traveloka assessment recommends Thailand or Singapore for an ASEAN pilot. The framework that produced that choice - which any OTA can apply to its own footprint - is below. Regulatory clarity is a filter, not a score: a market either passes it or it doesn't.

4.6 The Phase 1 go/no-go gates

Two gates close out Phase 1 and authorize pilot spending:

• Gate 1 - regulatory clearance. Written counsel memo confirming the pilot market is permissible via a licensed gateway, with documented consumer disclosures and tax treatment. No outstanding 'we should also check' items.
• Gate 2 - commercial clearance. Signed term sheet with the gateway. At the modelled pilot volume, the commercial terms must clear the EBITDA threshold set in Phase 0. If the gateway's commercials erode the case, the discipline is to renegotiate or pause - not to launch a thin-margin pilot.

5. Phase 2 - Pilot launch

Duration: 8–12 weeks to build, then a live run of roughly one quarter | Owner: Head of Payments, with Product, Engineering, Country GM | Outcome: a data-backed case from one market, and a go/no-go for regional rollout

Indicative cost: mostly internal engineering and product time for the build, plus the gateway's per-transaction fees once live. The supplier-payment track adds a custody platform fee and a working stablecoin balance (see 5.4). Keep a modest budget for promotional activity to drive customer-side adoption during the live run - without it, the adoption hypothesis is under-tested. Size these against the EBITDA threshold from Phase 0 before committing.

5.1 Scope discipline - what a pilot is and isn't

The most common failure mode at this phase is scope creep. A pilot is a controlled experiment to test three hypotheses. It is not a regional product launch.

• In scope: one market, one or two stablecoins (USDC and USDT), one or two networks per token, one gateway, one settlement currency. Optionally, a parallel supplier-payment pilot in the same or adjacent market.
• Out of scope (for now): multi-market launch, branded crypto wallets, holding stablecoin on the corporate balance sheet beyond the supplier-payment working balance, customer loyalty in stablecoin, supplier payments at scale.

Two decisions to settle before the build starts

Both sit with the Treasurer and General Counsel, and both are easier to decide now than to retrofit:

• Refund mechanics. Decide whether refunds are issued in fiat or in stablecoin, and who carries the price movement between the original payment and the refund. The cleaner default is to refund in fiat to the customer's chosen account, which keeps refund handling inside your existing process. Confirm this is disclosed to the customer before checkout.
• Custody of the supplier-payment balance. Holding even a small working stablecoin balance for the supplier track is a treasury-policy and balance-sheet question, not just an operational one. It needs Treasurer and (if your policy requires) board or audit-committee sign-off before the pilot starts - not as a discovery during it.

5.2 The three hypotheses to test

Everything the pilot does serves these three questions. Anything that doesn't help answer them is out of scope. The targets below are starting assumptions to set with your gateway and country team - not benchmarks.

5.3 The customer-side pilot - build sequence

A realistic build sequence, assuming a competent in-house payments team and a gateway with a mature integration. Timelines stretch if either is missing - flag that risk early rather than holding the dates.

• Weeks 1–2: Discovery, gateway sandbox onboarding, technical alignment, architecture sign-off.
• Weeks 3–4: Checkout integration - token selection, price quote, payment instruction. End-to-end sandbox transaction flowing.
• Weeks 5–6: Reconciliation to ledger, refund flow, customer support tooling. Operational handover dossier complete.
• Weeks 7–8: Quality assurance, security review, fraud and sanctions edge cases. Production readiness review.
• Week 9: Production cutover behind a feature flag - a small share of traffic first, then ramp to full in the pilot market.
• Weeks 10 onwards: Pilot live; weekly KPI review; biweekly steering committee. Cumulative dataset for the go/no-go.

5.4 The supplier-payment pilot - the parallel track

A supplier-payment pilot can be scoped more tightly than the customer-side one, because there is no consumer experience, no marketing dependency, and no consumer-protection layer.

Recommended pilot design

• Inventory category: a fragmented, hard-to-pay segment - typically activities and experiences, ground transport, or smaller hotels in markets with weak correspondent banking (e.g. Vietnam, Philippines, Cambodia, or parts of Latin America or Africa, depending on your footprint).
• Counterparty count: 10–25 suppliers, opted in voluntarily by your supply operations team. Never default suppliers into a new payment method.
• Mechanism: Treasury holds a working stablecoin balance on a regulated custody platform (sign-off per 5.1). The accounts payable system generates a payment instruction. The supplier receives the stablecoin and converts to local currency through their own on-ramp, or holds it.
• Controls: Standard segregation of duties (initiator, approver, releaser). Wallet whitelisting on the custody platform. Sanctions screening on each new supplier wallet, then periodically. On-chain monitoring through the custody platform.
• KPIs: All-in cost per payment versus current SWIFT and correspondent baseline; settlement time; supplier feedback; failed or recalled payment rate.

5.5 The pilot dashboard - what to report weekly

Targets are planning assumptions to set with the gateway and country team at the start of the pilot, then hold against. They are not industry benchmarks.

What's next

Part 3 covers what to do once the pilot is producing weekly data - how to scale beyond the first market, the full risk register, and the final prioritized recommendation. The decision point at the end of Part 2 is whether the pilot data clears the EBITDA threshold set in Phase 0. If it does, Part 3 turns the pilot into a regional program. If it doesn't, Part 3 still applies to the supplier-payment track, which can scale on its own.