Built for how Traveloka already runs payments.

Yuno is a global payment orchestration platform founded in 2022 by Juan Pablo Ortega (CEO, co-founder of Rappi) and Julián Núñez (COO, early Rappi executive — creator of Rappi's one-click checkout and former Head of E-Commerce at Rappi). Yuno was born to solve the complexity of managing multiple PSPs at scale, a challenge the founders experienced firsthand during Rappi's multi-country expansion.

Scale today

• 1,000+ payment methods integrated out of the box
• 450+ pre-integrated PSPs, acquirers, gateways, wallets, 3DS providers and fraud tools
• 180+ currencies supported
• 195+ countries in operational footprint
• Global office footprint across LATAM, North America, EMEA, MENA and APAC (Singapore HQ, China, India)
• Certifications: PCI DSS Level 1 (v4.0/4.0.1), SOC 2 Type II, ISO/IEC 27001, ISO/IEC 27701, GDPR-compliant, Visa Service Provider
• Parent entity: Yuno New York. Primary commercial entity for APAC contracting: Yuno Singapore — aligned with the NDA already in place with Traveloka.

OTA and travel references — signed and in production

Qatar Airways

MENA · Airline

Kiwi.com

Europe · OTA

Vueling

Europe · Airline

Copa Airlines

LATAM · Airline

JetSMART

LATAM · Airline

Viva Aerobus

LATAM · Airline

Yuno is deliberately PSP-agnostic — we do not own an acquiring licence and do not participate in the economics of any specific PSP. This is a core design choice that keeps our routing objective and aligns with Traveloka's stated preference for full control of the processor mix.

Yuno operates in 195+ countries with local teams across each priority region.

1st priority — SEA (ID, MY, TH, SG, VN, PH): Full card and APM coverage. Local PSPs/acquirers integrated include 2C2P, Xendit, Antom, HitPay, Fiuu, DOKU, DANA, GoPay, OVO, ShopeePay, Boku. APAC coverage is led from the Singapore APAC HQ, with additional regional staff across China (Shanghai, Beijing) and India.

2nd priority — APAC (AU, JP, KR): KCP, Hecto Financial, Toss Payments (KR); NTT Data, JP Morgan, GMO (JP/AU); Airwallex, Adyen, Checkout.com, Stripe, Worldpay, Unlimit (cross-APAC).

3rd priority — Global (US, EU, CN, Middle East): Adyen, Stripe, Checkout.com, Worldpay, Fiserv, Braintree, Cybersource, Nuvei, Airwallex, Unlimit, BNP Paribas, Paycomet, MPGS, QNB, Tap Payments, Network International (MENA); Redsys, Niubiz, EBANX, Payaza. China via Antom and 2C2P. India via BillDesk, Razorpay, PayU, CCAvenue.

Yuno supports 180+ ISO 4217 currencies across its PSP network. All currencies listed by Traveloka (IDR, THB, VND, MYR, SGD, PHP, AUD, JPY, KRW, USD, EUR, CNY, GBP, TWD, CHF, SAR, NZD, INR, AED, QAR, CAD, HKD, BRL, BHD, OMR, EGP, PKR, KWD, JOD) are supported through at least one — and in most cases multiple — processors in the Yuno network.

Settlement currency per country is a function of the chosen acquirer; Yuno supports like-for-like settlement in all priority SEA and APAC currencies via at least one network acquirer, removing FX exposure at the processing layer.

All global networks — Visa, Mastercard, American Express, JCB, Discover, Diners Club, UnionPay — are fully supported.

Local networks supported:

• Korea: Shinhan, Samsung, Hyundai, Woori, BC, Hana, Kookmin (KB), NongHyup, Lotte — via KCP, Toss Payments, and NTT Data.
• Australia: eftpos via Adyen and local acquirers.
• India: RuPay and UPI via Razorpay, BillDesk, PayU (UPI Autopay in production; expansion underway via BillDesk, Razorpay, and Adyen).
• Brazil: Elo, Hipercard.
• Japan: JCB directly and via JP local acquirers.
• China: UnionPay for CNY via Antom and 2C2P.

Yuno supports Apple Pay and Google Pay with full DPAN (Device PAN) + cryptogram (TAVV for Apple Pay, CAVV for Google Pay) flows as the default mechanism.

Three integration models available, chosen per Traveloka's preferences:

1.Yuno SDK — fastest path; Yuno handles the Apple/Google Pay button, sheet, token decryption, and routing. Recommended for Traveloka app contexts where speed-to-market is a priority.

2.Direct — Traveloka controls the Apple/Google Pay front-end fully; Yuno's API receives the encrypted token, decrypts server-side in Yuno's PCI environment, and routes to the configured acquirer.

3.Via Provider — pass-through; Yuno forwards the encrypted token to the downstream PSP that owns the Apple/Google Pay merchant ID.

Supported card networks over wallets: Visa, Mastercard, Amex, Discover, JCB globally; Elo / Maestro in Brazil. FPAN is also supported for legacy PAN_ONLY flows (e.g. saved cards in Google account without a device cryptogram).

All currencies listed by Traveloka where Apple Pay / Google Pay are technically available (AUD, SGD, VND, MYR, JPY, USD, EUR, KRW, THB) are fully supported.

Reference documentation: https://docs.y.uno/docs/wallets/google-pay and https://docs.y.uno/docs/wallets/apple-pay.

Yuno supports two installment models natively:

1.Merchant Installments — Traveloka defines the installment plan (amount, tenure, interest) at checkout, Yuno authorises the card for the total amount, and Traveloka manages downstream settlement logic internally. Supported globally for any issuer.

2.Provider Installments — Yuno passes the installment plan to the downstream acquirer/PSP, and the issuing bank books the plan for the cardholder. Supported where the PSP supports it (e.g. Adyen, Cybersource, 2C2P, EBANX, Omise, GMO (JP), PayU).

SEA installment coverage (typical tenures vary by issuer):

• Indonesia: BCA, Mandiri, BNI, BRI, CIMB — typically 3/6/12 month tenures via DOKU, Midtrans, 2C2P.
• Thailand: K+, Krungsri, SCB, KTC, TMB, Bangkok Bank — 3/6/10 tenures via 2C2P, Omise, GBPrimePay.
• Malaysia: Maybank, CIMB, Public Bank, RHB, Hong Leong — 3/6/12/24 tenures via Fiuu, HitPay.
• Singapore: DBS, UOB, OCBC, Citi — 3/6/12/24 tenures via Stripe and 2C2P.
• Vietnam: Vietcombank, Techcombank, VPBank, Sacombank — 3/6/12 tenures via 2C2P and local acquirers.

Mechanism: fallback logic is supported — if the primary provider cannot honour the plan, Yuno can route to another provider offering the same plan for the same issuer.

Yuno supports 1,000+ payment methods including account-to-account (A2A) rails, e-wallets, cash voucher, BNPL, and bank transfers across the Traveloka currency list.

Highlights per SEA market:

• ID: DANA, GoPay, OVO, ShopeePay, LinkAja, QRIS, Indomaret, Alfamart, BCA VA, Mandiri VA, BNI VA, BRI VA, Permata VA, Akulaku, Kredivo
• TH: PromptPay, TrueMoney, LINE Pay, K+, ShopeePay, Counter Service, Cash at Tesco/Big C
• MY: FPX, Boost, Touch 'n Go, GrabPay, ShopeePay, MaybankQRPay
• SG: PayNow, GrabPay, ShopeePay
• VN: MoMo, ZaloPay, VNPay QR, Airpay, bank transfer
• PH: GCash, Maya (PayMaya), GrabPay, 7-Eleven, Cebuana Lhuillier
• AU: POLi, PayID, BPAY, Apple/Google Pay
• JP: Konbini (Lawson, FamilyMart), Pay-easy, PayPay, MerPay, Rakuten Pay
• KR: KakaoPay, Naver Pay, Toss Pay, Payco, Korean bank transfer
• IN: UPI, UPI Autopay, Paytm Wallet, NetBanking

Local entity & NRA: For most APMs, Traveloka Singapore can remain the contracting legal entity, and settlement can happen locally via Non-Resident Accounts (NRA) or via like-for-like settlement through the local PSP. Exceptions (where a local entity or local licensee is required) exist for specific regulated domestic rails — to be confirmed per APM.

1.Yes — Yuno is fully PSP-agnostic. We have 450+ PSPs, acquirers, gateways, 3DS providers and fraud tools pre-integrated. A live list is maintained in the Yuno Dashboard under Connections. Selected APAC-relevant integrations: Adyen, Airwallex, Checkout.com, Stripe, Worldpay, Fiserv, Braintree, Cybersource, Nuvei, Unlimit, 2C2P, Antom, Xendit, HitPay, Fiuu, DOKU, Midtrans, Omise, GBPrimePay, NTT Data, KCP, Hecto Financial, Toss Payments, PhonePe, Razorpay, BillDesk, PayU, CCAvenue, EBANX, JP Morgan.

2.Custom PSP integration commitment: If Traveloka requires a PSP not currently in the Yuno network, Yuno commits to integrate it on Traveloka's behalf at no additional integration fee, subject to the PSP's own onboarding process. Typical new-PSP integration timeline is 4–8 weeks depending on API complexity and certification scope; a concrete SLA will be committed to in the MSA.

3.Own processor / acquiring: Yuno does NOT own any acquirer, processor, or issuing licence. This is deliberate and structural — it is the single cleanest guarantee of routing objectivity. Yuno does not participate in the per-transaction economics of any downstream PSP; Yuno's revenue is a flat orchestration fee, which is identical regardless of which downstream PSP handles each transaction. Traveloka fully owns the routing logic and PSP mix. Given Traveloka's stated preference for full transparency and self-determined processor mix, this structure is a direct fit. No separate Payment Gateway proposal is required as Yuno does not operate as an acquirer or gateway.

All eight APIs are fully supported as part of Yuno's public REST API (https://docs.y.uno/reference).

• Authentication — OAuth / API Key (public + private secret) with HMAC-signed webhooks.
• Authorization (Sales) — POST /v1/payments, supports auto and manual capture flows, 3DS pre-authenticated data, network tokens, stored credentials.
• Capture — POST /v1/payments/{id}/transactions/{tid}/capture (full or partial).
• Auth Reversal — POST /v1/payments/{id}/transactions/{tid}/cancel on an uncaptured auth.
• Void — the same cancel endpoint applied to the transaction prior to settlement.
• Refund — POST /v1/payments/{id}/transactions/{tid}/refund (full or partial).
• Transaction Status / Inquiry — GET /v1/payments/{id} and GET /v1/payments/{id}/transactions.
• Webhook / Notification — configurable via Dashboard, HMAC-signature verification, delivery retry with exponential backoff; full event catalogue at https://docs.y.uno/docs/webhooks.

Additional APIs available (beyond the eight required): Customers, Sessions, Checkout, Enrollment (tokenisation), Subscriptions, Payouts, Chargeback Management, Risk Conditions (fraud), Account Updater, Split Payments (marketplace), MCP Remote Server for AI agents.

Full API reference: https://docs.y.uno/reference. OpenAPI spec and Postman collection available on request. All APIs support idempotency keys.

Yuno supports both Network Tokenisation and Gateway (Vaulted) Tokenisation out of the box.

Network Tokenisation

1.Yuno has direct relationships with Visa (VTS), Mastercard (MDES) and American Express; network tokens are provisioned automatically for any enrolled card where the issuer supports the programme.

2.Traveloka can be the Token Requestor of record — tokens are associated to Traveloka's TRID. This is configurable per merchant organisation at setup.

3.Yuno can process transactions using network tokens provisioned by other Token Requestors (e.g. Cybersource, Adyen). This is supported via Yuno's Network Token Migration Process (https://docs.y.uno/docs/network-token-migration-process) and the raw-token pass-through flow documented at https://docs.y.uno/docs/network-tokens.

4.Yuno can also export network tokens (PAR, cryptogram input) so Traveloka can use them with other partners. Yuno exposes an API to retrieve the cryptogram (TAVV / CAVV) for a given network token. We have previously validated with Cybersource that they can export network tokens into Yuno's infrastructure — enabling cross-requestor interoperability for Traveloka's existing token estate.

Gateway / Vault Tokenisation

1.Yuno runs a PCI DSS Level 1 Vault at the organisation level — a single vaulted token works across all connected PSPs in the Yuno network, avoiding re-tokenisation when a new PSP is added.

2.Full-PAN retrieval: Yuno supports a controlled PAN-export process (PGP-encrypted CSV via Yuno-hosted SFTP) — Traveloka must present a valid AOC (PCI DSS Level 1) and follow the documented export procedure. See https://docs.y.uno/docs/exporting-tokens-from-yuno. Exported fields include holder_name, number, token, expiration_month, expiration_year. Data-in-transit is encrypted with Traveloka's PGP public key.

1.Yuno operates a fully merchant-configurable Dynamic Routing engine managed from the Dashboard → Routing section. For any payment method, routes are defined as if/then rules with an unlimited number of conditions and steps. Conditions can combine country, currency, amount, BIN, card brand, card type (credit/debit), IIN, time of day, issuer, merchant-defined metadata, customer attributes, 3DS outcomes, and fraud-score output. Each route step can be a 3DS provider, fraud tool, or acquirer/processor, and Yuno supports multi-step flows (3DS → fraud → primary PSP → fallback PSP). A live walkthrough can be arranged via a sandbox account.

2.Yuno's Smart Routing feature layers machine learning on top of the rule engine. It observes per-transaction signals (BIN, country, amount, time of day, issuer response history) and scores each candidate PSP for expected approval probability in real time. Models continuously learn from the aggregate Yuno transaction corpus while keeping each merchant's data isolated at inference time. Smart Routing runs at first-attempt authorisation and at retry stages. Reference: https://docs.y.uno/docs/routing.

3.Full merchant ownership. Every routing rule is visible, editable, and version-controlled in Traveloka's Dashboard. No Yuno user can change the routing logic without explicit merchant authorisation. Traveloka can export / document the ruleset at any time.

4.Flexibility: Routing rules can be published, unpublished, and switched live at any time; changes take effect immediately for subsequent transactions. Traveloka may define role-based access so only the Payment team can change routing.

5.Additional data: Traveloka can pass any custom field in the payment request (under `metadata` — JSON object, up to the configured size limit per object) and use it in routing conditions. Common use cases: customer_segment, booking_vertical (flight/hotel/experience), channel (app/web), prior_successful_psp.

6.A/B testing: Yuno's routing engine supports volume-splitting on any route step (e.g. X% to PSP A vs PSP B). The Dashboard and Monitors display per-arm approval rate, cost, latency, and chargeback rate. Results export via Insights.

Yuno supports three complementary retry mechanisms:

1.In-flight retry (single authorisation): Yuno's routing engine can retry an authorisation across up to N PSPs automatically based on the decline reason (soft declines, issuer unavailable, and insufficient-funds patterns are handled differently). Typical configuration is 2–4 PSP fallbacks per attempt, fully configurable.

2.Smart Retries (MIT / recurring): uses an ML-scheduled retry cadence — typically up to 7 attempts over a 7-day window (5 min, 60 min, 5 h, 24 h, 48 h, 96 h), dynamically adjusted per decline pattern and issuer.

3.Transaction Retries (capture / refund failures): retries up to 7 times within 96 hours with a fixed back-off.

Retrying 3DS-authenticated transactions without re-prompting is supported. Yuno uses a standalone 3DS MPI (external to the acquirer). Once the cardholder has been authenticated, the resulting CAVV/ECI/XID can be re-used across multiple acquirer retries without triggering a second challenge — provided each downstream acquirer accepts pre-authenticated 3DS data (most major acquirers do; this is live with Cybersource, Adyen, Checkout, Airwallex, Worldpay). If an acquirer's 3DS is embedded rather than standalone, retry is constrained by that acquirer's policy.

Customisation: Traveloka can define separate routing rules for retry transactions (e.g. first attempt to PSP A, retries to PSP B / C; exclude specific decline codes from retry; apply different 3DS rules per retry). Configuration lives in Dashboard → Routing → retry branch.

Yes. Yuno Payment Links allow a Traveloka ops user to generate a shareable URL from the Dashboard (or via API). The link renders Yuno's hosted Checkout, accepts card + APMs per Traveloka's configured catalogue, applies the same routing / 3DS / fraud rules as the main flow, and reports into the same Dashboard. Typical use cases: manual rebookings, refund capture, corporate invoicing, customer recovery.

Each PSP / acquirer credential (API keys, secrets, PKCS12 certs, etc.) is entered by the merchant directly in the Yuno Dashboard → Connections section, where it is encrypted at rest in Yuno's PCI-compliant vault. Yuno does not request or store credentials in plain text in any ticketing system or email.

Rotation: Keys can be rotated at any time by the merchant without integration changes. Rotation cadence follows each PSP's own policy — some (e.g. Stripe) allow indefinite validity, others mandate yearly rotation. Yuno provides reminder notifications when a credential expiry is approaching. Yuno's own public API keys used by Traveloka can be rotated via Dashboard → Developers (Credentials) with zero downtime — a pair of active keys is supported during rotation.

Access to the encrypted vault is RBAC-controlled, audit-logged, and HSM-backed (FIPS 140-2 Level 3+ via AWS CloudHSM / Thales Luna / Utimaco).

Every enterprise Yuno merchant is assigned a dedicated APAC-based Key Account Manager (KAM) supported by a dedicated Technical Account Manager (TAM). For Traveloka, the KAM will be APAC-based in the same timezone as Traveloka. The standard enterprise programme includes:

• Monthly performance review with a structured scorecard — approval rate by corridor, decline-code breakdown, cost per transaction, share-of-wallet per PSP, incident summary
• Quarterly Business Review with senior Yuno leadership
• Dedicated Slack Connect channel for day-to-day operational support
• Priority access to Yuno's payments engineering team for routing tuning experiments
• Data-driven optimisation recommendations (routing, 3DS, retry) sourced from Yuno's Data team

Yuno aggregates payment performance data across its merchant base and will provide a benchmark view sliced by:

• Currency (IDR, THB, VND, MYR, SGD, PHP, AUD, JPY, KRW, USD, EUR)
• Card brand (Visa, Mastercard, Amex, JCB)
• Transaction type (cross-border vs domestic)
• Industry (OTA / travel)

Published Yuno benchmarks (illustrative, to be refreshed with FY2025 data for Traveloka):

• Shifting US cross-border card traffic to local domestic acquiring lifts first-attempt approval by ~10pp in many corridors
• Adding a second or third acquirer on a local route typically delivers a consistent +1–3pp uplift
• Smart Routing and Smart Retries together typically recover a meaningful share of failed MIT transactions

Yuno's performance-uplift programme for Traveloka combines four levers:

1.Multi-PSP routing & fallback — Establish 2–3 local acquirers per priority SEA currency (e.g. 2C2P + Adyen + domestic acquirer for TH; DOKU + Adyen + Midtrans for ID). Smart Routing selects the highest-probability PSP per transaction in real time. Typical uplift: +3–8pp depending on currency.

2.Local card acquiring migration — Shift cross-border card volume to local acquirers where available.

3.Network tokenisation + Card Account Updater — Reduce stale-credential declines meaningfully on saved-card / repeat-booking customers.

4.3DS optimisation — Run 3DS exemption logic (low-value, recurring, trusted beneficiary, TRA) where supported; use BIN-mandate mapping to skip 3DS where the issuer country does not mandate SCA. Expected: approval uplift + reduced cardholder abandonment.

Yes. Yuno supports three integration models; Traveloka can own the UI completely if preferred.

1.Yuno SDK (Full / Lite Checkout) — fastest time-to-market, PCI scope reduced to SAQ-A. Not required if Traveloka wants full UI control.

2.Secure Fields / Headless SDK — Traveloka owns 100% of the UI. Card fields are embedded as Yuno-hosted iframes; raw PAN never touches Traveloka's servers. PCI scope remains SAQ-A.

3.Direct Flow (Server-to-Server) — full raw card data flow; Traveloka's servers handle PAN and must provide its own PCI DSS Level 1 AOC. Yuno supports this for PCI-certified merchants and exposes the same routing, 3DS, tokenisation, and reconciliation features. Traveloka would remain SAQ-D / PCI Level 1 in this case.

SDKs available for Web (JavaScript), iOS, Android, Flutter, React Native, plus headless variants for custom UIs. Reference: https://docs.y.uno/docs/web-sdk and https://docs.y.uno/docs/secure-fields.

Full API reference is publicly available at https://docs.y.uno/reference. Orchestration-specific endpoints and docs:

• Routing — https://docs.y.uno/docs/routing
• Smart Retries — https://docs.y.uno/docs/retries
• Transaction Retries — https://docs.y.uno/docs/transaction-retries
• 3DS Configuration — https://docs.y.uno/docs/3d-secure
• Tokens — https://docs.y.uno/docs/tokens
• Network Tokens — https://docs.y.uno/docs/network-tokens
• Webhooks — https://docs.y.uno/docs/webhooks

OpenAPI spec, Postman collection, and SDKs (Web / iOS / Android / Flutter / React Native) available on request. Documentation is updated with each API release and includes request/response schemas, error codes, and code samples.

Yuno operates on AWS multi-region infrastructure. Operational posture:

1.SLO uptime: 99.99% target for the core payments API. Historical actual uptime over the last 24 months and incident history is published at https://status.y.uno/.

2.Latency: Yuno's orchestration overhead (ingress → response, excluding downstream PSP latency) is engineered for low p50/p95 impact.

3.Health metrics: real-time Status Page (https://status.y.uno/), 24×7 monitoring, automated alerting. Yuno's Monitors feature inside the Dashboard gives Traveloka per-PSP real-time approval-rate and latency views.

4.Downtime compensation: Yuno's standard MSA contains service-credit remedies tied to monthly uptime SLAs. Specific credit tiers and thresholds to be agreed in the MSA.

A named, APAC-based TAM is assigned from day one and remains the technical point of contact for the life of the contract. Responsibilities include:

• Leading the integration workshop and solution design
• Driving sandbox testing, certification with each PSP, and go-live
• Post-go-live technical optimisation (routing, 3DS, retry tuning)
• Incident escalation ownership
• Monthly technical review with the Traveloka engineering team
• API versioning / deprecation communication

The TAM is complemented by a shared Slack Connect channel with Yuno's on-call engineering team for incident response.

Yuno provides a fully featured Sandbox at https://api-sandbox.y.uno with:

• Mirror of production API endpoints
• Full Dashboard (sandbox.y.uno) for routing / connection setup
• Yuno Testing Gateway — a simulated PSP that returns deterministic success / failure outcomes via test card numbers and magic amounts (https://docs.y.uno/docs/yuno-testing-gateway)
• Per-PSP test credentials for certification (Yuno provisions shared test acquirers for each PSP on request)
• 3DS challenge simulation (frictionless / challenge / failed)
• Webhook receiver for async testing
• No rate limits in sandbox; independent sandbox per merchant account

Yuno's commercial model is transparent, modular, and decoupled from downstream PSP economics. Headline components for Traveloka:

• Per-transaction success fee, tiered by monthly card volume — applies only to successfully authorised transactions
• Monthly platform licence fee covering the full orchestration platform, dashboard, unlimited connections, unlimited users
• Optional add-ons for Yuno 3DS and Network Tokens (priced per use below)
• No per-PSP / per-acquirer connection fees — any future PSP added on Traveloka's behalf is included at no additional cost
• No Yuno mark-up on PSP fees — downstream PSP/acquirer economics flow directly from the PSP to Traveloka

Per-transaction pricing (USD per successful authorisation)

Platform licence and add-ons

All pricing is in USD; EUR available on request. Pricing stays valid for the initial contract term and is subject only to the standard annual CPI adjustment clause in the MSA.

Yuno's merchant onboarding is lightweight because Yuno is not an acquirer — there is no holding of funds and no merchant underwriting by Yuno. The process:

1.Commercial sign-off (Order Form + MSA + DPA)

2.Technical kick-off call

3.Compliance pack: Yuno requests a minimal KYB pack (certificate of incorporation, director IDs, basic beneficial ownership, AML questionnaire, sanctions screening). Typically completed in 3–5 business days.

4.Technical integration workshop

5.Sandbox certification with selected PSPs

6.Production credentials issued

7.Go-live

Traveloka will need to onboard separately with each selected PSP / acquirer (since Yuno does not hold funds). The Yuno KAM / TAM coordinates this and supports each PSP onboarding.

Collateral / deposit: Not required by Yuno — funds never touch Yuno's balance sheet. Individual acquirers may set their own rolling reserves per Traveloka's direct agreement with them; Yuno has no commercial interest in that.

Confidential documents: Yuno Compliance can accept alternative documentation (externally-audited statement, letter from counsel) where a specific KYB document is confidential. Integration is not delayed due to confidential-document exchange.

Yuno's group structure:

• Parent entity: Yuno New York
• APAC contracting entity (preferred for Traveloka): Yuno Singapore
• Regional operating presence across LATAM and EMEA (specific entities disclosed during contracting as needed)

Payment licences: Yuno does NOT hold payment / acquiring licences because Yuno is a technology orchestrator, not an acquirer. The underlying acquirers / PSPs in the Yuno network hold local licences in their own right. Local settlement currencies are a function of the selected acquirer per market.

Like-for-like processing: supported in all priority currencies (IDR, THB, VND, MYR, SGD, PHP, AUD, JPY, KRW, USD, EUR, CNY, GBP, TWD, CHF, SAR, NZD, INR, AED, QAR, CAD, HKD) via at least one network acquirer.

Agreed. Where Yuno's fees apply, they are billed on the processing-currency amount (not the FX-converted settlement amount). FX conversion applies after the net payable is calculated.

FX arrangement: Yuno does not hold funds, so FX is typically an acquirer-level mechanism. If an FX arrangement is introduced in a Yuno-bundled commercial, Yuno will disclose any FX mark-up up-front in the Order Form and provide the daily reference rate source (typically WM/Reuters or Bloomberg closing rate). Traveloka retains the right to use its own FX bank partner for settlement currency conversion — see F.2.

Yuno's Reconciliations module ingests settlement reports from each connected PSP (via SFTP, API, or email) automatically, normalises the data to a single schema, and cross-checks against Yuno's own authorisation and capture records. Features:

• Automated ingestion from each PSP (no manual upload needed)
• Settlement vs transaction matching with per-line status (settled / missing / mismatch)
• Unified report across all PSPs in Dashboard → Reconciliations
• Settlement-missing alert — if a PSP does not deliver a settlement file within its SLA, Traveloka can configure an automated email alert
• CSV / JSON export and scheduled delivery to S3 / SFTP
• Transaction-level settlement data including gross, fees, net, PSP, method, currency; Yuno IDs mapped to PSP reference IDs for audit

Customised report definitions (columns, filters, cadence) are configurable by Traveloka.

Yuno's Chargeback Management module aggregates dispute notifications from every connected PSP into a single dashboard. Features:

• Dispute lifecycle tracking (notification → response → represent → final ruling)
• Unified schema with dispute_amount, reconciliation_amount, reason_code, reason_category (Fraud / Authorisation / Processing Error / Consumer Dispute), action_due_date, dispute_stage (Retrieval / Chargeback / Pre-arbitration / Arbitration), network (Visa / Mastercard / Amex / JCB), and deduction fees
• Evidence upload and centralised response workflow
• Export as CSV / JSON; scheduled delivery option
• Fraud rate metrics (chargeback rate, fraud decline rate, false positive rates); trend analysis by method, currency, country, BIN
• Transaction-level analysis with risk scores and rationale

Dispute response codes are normalised to Yuno's taxonomy (https://docs.y.uno/docs/chargeback-response-codes). Historical data is available via Dashboard, API, and scheduled email / SFTP delivery.

Invoicing with Yuno:

• Invoice currency: USD (default); EUR available on request
• Invoicing entity: Yuno Singapore (the same APAC contracting entity set out in A.1 and D.3)
• Cycle: Monthly — invoice issued within 5 business days of month-end
• TOP: Traveloka's 60-day standard is acceptable
• Payment channel: bank transfer to Yuno's designated account (wire details on the invoice); other channels by mutual agreement
• Delivery: secure email PDF plus the Dashboard Invoice view

Agreed. Because Yuno does not hold funds, the settlement currency is set at the acquirer level. Traveloka's preference to use its own FX arrangement with its bank is fully supported — the selected acquirer settles in the actual processing currency (or nearest like-for-like), and Traveloka converts via its own bank.

For Yuno-billed fees (orchestration, vault, CAU, etc.) we invoice in USD by default and allow Traveloka to pay in its preferred currency using its own FX arrangement with its bank partner.

Yuno operates an in-house fraud capability called Risk Conditions, available as a standalone engine and as an orchestration layer to external FDS (Forter, Riskified, TrustDecision, Signifyd, Sift, Ravelin, Cybersource Decision Manager, Adyen RevenueProtect, and others).

Capabilities:

• Pre-authorisation checks — rules-based + ML scoring before the transaction is sent to the acquirer
• Post-authorisation checks — after acquirer response, before capture (for two-step flows)
• Machine-learning risk score — 0–100 score combining velocity, device, BIN, behaviour, and geolocation signals
• Anomaly detection — unsupervised anomaly flags (unusual booking time, unusual amount distribution, new device, impossible-travel)
• Rule engine — merchant-configurable rules with any Yuno field + metadata
• Chain-of-trust — combine Yuno Risk Conditions with one or more third-party fraud tools in sequence; each can return an OUT_OF_SCOPE / REVIEW / DECLINE verdict used in routing

No separate API required for inline fraud checks. Fraud steps are part of the routing engine: Traveloka adds a fraud step (Yuno Risk Conditions or any third-party tool) in the route at pre-auth or post-auth position. The transaction is submitted through the standard POST /v1/payments endpoint and the fraud engine is invoked inline.

If Traveloka prefers a standalone risk-check call (e.g. to score a transaction before creating a payment object), Yuno also exposes a Risk Score API that returns the score and verdict as a separate call. Both modes can be used simultaneously.

Yes — a dedicated fraud analyst can be assigned as part of the KAM / TAM programme for enterprise accounts. Responsibilities:

• Weekly / monthly rule tuning based on observed fraud-to-approval ratios
• Decline-code attribution analysis
• Chargeback root-cause review
• Joint work with Traveloka's fraud ops team on thresholds and segmentation
• Coordination with any third-party FDS vendor Traveloka uses

Visibility:

• Full transaction data (amount, currency, method, card BIN, PSP, auth code, decline reason, 3DS status, risk score, routing decision, retry history, settlement status) available via Dashboard and API
• 200+ fields per transaction, including raw PSP response, decline codes, fraud score, device fingerprint, 3DS data
• Yuno stores transaction records for the full lifetime of the merchant contract, queryable via Dashboard, Insights and API
• Online (Dashboard) retention: granular transaction data is queryable in the Dashboard for the duration of the merchant contract; full historical data is also available via API export and archival for the entire contract duration
• Data latency: transactions are queryable in the Dashboard within ~60 seconds of authorisation; webhook notifications are sent in real time

Long-term archival can additionally be configured to Traveloka's own S3 bucket at no additional cost.

Yes. Yuno exposes bi-directional fraud-flag sync:

• Inbound webhooks — Yuno pushes fraud flags, decline reasons, and chargeback notifications in real time to Traveloka's systems
• Outbound APIs — Traveloka can push fraud verdicts, blacklists (card, email, IP, device), and risk-review outcomes back to Yuno to inform future routing decisions
• Shared case management — fraud-related transactions can be tagged with Traveloka's internal case ID via metadata and made searchable in Yuno's dashboard
• Shared blacklist / allowlist API — Traveloka maintains lists in one place and Yuno enforces them across all connected PSPs

The feedback loop continuously improves Yuno Risk Conditions model performance.

Yuno offers end-to-end support for fraud investigations:

• Data provision — full raw transaction and PSP response data available on request
• Joint investigation — Yuno's fraud analyst participates alongside Traveloka's fraud team for major incidents
• Liaison with downstream PSPs and card networks — Yuno coordinates data requests, representment evidence, and incident escalation across the PSPs in the merchant's routing stack
• Chargeback representment — Yuno's Chargeback Management module manages the response workflow; for disputed cases, Yuno's analyst supports evidence preparation
• Regulatory / legal cooperation — Yuno responds to formal law-enforcement requests following a documented process

Monthly fraud review meetings with the KAM / CSM cover BIN-level / issuer-level analysis, decline-code trends, and representment outcomes. Yuno does not act as a financial investigator of last resort (that role remains with the acquirer and card networks), but Yuno's role is substantive and not limited to data pass-through.

Yes. Yuno's Dashboard (https://dashboard.y.uno) is real-time. Key views:

• Home — real-time transaction volumes, approval rate, decline-reason breakdown, cost-per-transaction
• Payments — full transaction search with sub-second query latency
• Insights — aggregated analytics with custom date ranges, cohort views, comparisons across PSPs
• Monitors — real-time alerts on approval-rate drops, PSP latency, decline-code spikes, customisable alerts
• Reconciliations — real-time settlement status
• Routing — live routing rules with role-based access control and version history
• Chargebacks — live dispute pipeline
• Connections — PSP credentials and API key management
• Developers — webhook configuration, event log, API key rotation
• Teams & Roles — granular RBAC with SSO (SAML via Microsoft Entra ID, Okta); audit logs

Transactions appear in the Dashboard within ~60 seconds of authorisation. Real-time websocket updates on the Payments view.

Online retention in the portal: granular transactional data is retained for the duration of the merchant contract.

Historical data: available via API export and archival for the entire contract lifetime — Yuno can deliver transaction records to Traveloka's S3 bucket at no additional cost.

Aggregate (summarised) Insights available for the full contract duration without limit.

Disposal: secure deletion aligned to PCI DSS v4.0.1 Requirement 3.1; cryptographic key destruction for card-data token vault.

Traveloka-customised retention is configurable in the contract.

Yuno provides maintenance and incident notifications via:

• Status Page (https://status.y.uno/) — subscribe via email, SMS, webhook, RSS, or Slack
• Email to a designated Traveloka distribution list
• Slack Connect channel (operational real-time)
• Dashboard banner for wide-impact events
• Webhook to Traveloka's systems for automated handling

Incident and scheduled maintenance both follow the same notification model. Post-maintenance confirmation is sent on completion.

Scheduled maintenance: minimum 7 calendar days advance notice (typically 14 days for non-urgent maintenance), via Status Page + email + Slack Connect + Dashboard banner.

During the event: updates on Status Page at 30-minute intervals (or more frequent for customer-impacting work); real-time updates in Slack Connect.

Maintenance is scheduled during low-traffic windows with redundant infrastructure minimising impact.

Incident notification SLAs (representative — final wording to be confirmed in the MSA):

• Major / total outage (Severity 1): initial notification within 15 minutes of detection; updates every 30 minutes until resolution; post-incident report within 5 business days
• Partial outage / degraded performance (Severity 2): initial notification within 60 minutes; hourly updates until resolution
• Minor incident / single-PSP issue (Severity 3): notification within 4 hours
• Cosmetic / non-impacting (Severity 4): next update cycle

All notifications delivered via Status Page, email, Slack Connect, and (for Sev 1) direct call to Traveloka's designated escalation contacts.

Yes — Yuno operates 24×7 support with APAC-time coverage:

• Shared Slack Connect channel for day-to-day operational issues with on-call rotation
• Ticketing portal for tracked issues with SLA-backed response
• Email: support@y.uno
• Emergency phone escalation for Severity 1 incidents (hotline number issued at onboarding)
• Follow-the-sun on-call rotation across APAC, EMEA, Americas

Enterprise clients receive priority support with faster response SLAs and direct escalation paths.

Yes. For any Severity 1 or Severity 2 incident, Yuno issues a formal post-mortem within 5 business days of resolution. Contents:

• Incident timeline (detection, mitigation, resolution)
• Root cause analysis (including blameless contributing factors)
• Impact assessment (transactions / volume / merchants affected)
• Corrective actions with owners and target dates
• Preventive measures

Post-mortems are shared via email and discussed in the monthly operational review with Traveloka. Follow-up actions are tracked to completion and reported back.

Response SLA by severity (indicative — final numbers in the MSA):

• Severity 1 — Total outage / critical payment impact: 15 minutes response, active work until resolution
• Severity 2 — Partial outage / significant degradation: 1 hour response
• Severity 3 — Minor issue / single-flow failure: 4 hours response
• Severity 4 — Bug / improvement request: next business day response

Phone / on-call escalation available for Sev 1 / Sev 2. SLA breach penalties (service credits) to be agreed in the MSA.

Yuno's Incident Management Policy (documented in the ISMS aligned to ISO 27001 and PCI DSS) covers:

• Detection & classification (Sev 1–4)
• Escalation matrix (on-call → Head of Engineering → Head of SecOps → CTO → CEO, depending on severity and duration)
• Communication protocol (internal + external, frequency per severity)
• Command structure (Incident Commander role)
• Forensics and evidence preservation
• Post-mortem and corrective-action process
• Regulatory notification (card networks, DPAs) where applicable
• Customer notification (per I.5)

The policy is audited annually as part of PCI DSS Level 1 and SOC 2 Type II programmes. The full policy document is available under NDA.

Yuno is PCI DSS Level 1 Service Provider (the highest tier, >6M transactions/year). Scope covers the full Yuno payments platform including tokenisation vault, network token provisioning, SDKs (Web / iOS / Android), Secure Fields, Direct API, Dashboard, Reconciliations, Chargeback Management, and merchant vault.

AOC validity and renewal: Yuno's current AOC is valid under PCI DSS v4.0 / v4.0.1. The AOC is renewed annually via QSA assessment. The current AOC is available for download from Yuno's Trust Centre at https://security.y.uno/. Yuno commits to providing a refreshed AOC annually on renewal (within 90 days of assessment completion) — this commitment will be written into the MSA and failure to do so is a material compliance breach.

Responsibility matrix: Yuno maintains a formal PCI DSS Shared Responsibility Matrix that maps each PCI DSS v4.0.1 control to Yuno (as TPSP), Traveloka (as merchant), and AWS (as infrastructure provider)..

Card Data Protection policy (aligned to PCI DSS, ISO 27001, SOC 2):

• Storage: card data is stored only in Yuno's PCI-segmented vault. AES-256 encryption at rest. PAN is tokenised before any non-PCI system receives it.
• Processing: card data is processed only within PCI-scoped microservices (PCI vault, tokenisation, network token, Apple/Google Pay PCI services). Logically isolated AWS accounts.
• Transmission: TLS 1.3 end-to-end (TLS 1.2 backward-compat only), mTLS between internal services, HSM-backed key management (FIPS 140-2 Level 3+); HSM providers: AWS CloudHSM, Thales Luna, Utimaco, Azure Managed HSM.
• Access control: RBAC + Privileged Access Management for all access to the PCI environment; no customer data exported from the CDE except via the secured Export flow (PGP-encrypted via SFTP, authorised recipients only with valid AOC).
• Monitoring: 24×7 SIEM, SAST (SonarQube), quarterly ASV scans, annual penetration tests by independent QSA.

Full Information Security Policy (ISMS) available via the Trust Centre.

Yuno itself does not hold payment / acquiring licences — Yuno is a technology orchestrator, not an acquirer. The underlying PSPs / acquirers in the Yuno network hold local licences in their own right.

For each Traveloka currency, Yuno can confirm that at least one licensed acquirer is available in-market. A matrix of licensed acquirers per priority market (ID: BI / OJK; MY: BNM; TH: BoT; SG: MAS; PH: BSP; AU: AUSTRAC/ASIC; JP: FSA; KR: BoK; IN: RBI; etc.).

For every acquirer / PSP in the Yuno network, Yuno performs initial and ongoing due diligence — licence verification with the local regulator, scope of approved activities, AML / sanctions history, and financial stability. Due-diligence policy is part of Yuno's Third-Party Risk Management (TPRM) programme (a SOC 2 control). For any new PSP onboarded on Traveloka's behalf, this check is included in the onboarding SLA and evidence is archived in Yuno's TPRM register.

Hosting: Yuno runs exclusively on AWS. Primary hosting: AWS US (us-east-1 / us-west-2). AWS facilities are compliant to ISO 27001, 27017, 27018, 27701, PCI DSS Level 1, C5, and CISPE Code of Conduct.

Business Continuity / Disaster Recovery: Yuno maintains a formal BCP and DRP. BCP / DR tests are conducted at least annually (tabletop exercises + live failover drills). Typical targets: RTO 4 hours for core payments; RPO 15 minutes. Both plans are reviewed annually by internal audit and assessed by external QSAs for PCI DSS compliance (BCP Requirement 12.10 under v4.0.1).

Cybersecurity (ISMS): Yuno operates a formal ISMS certified under ISO/IEC 27001. Components include Risk Management Policy, Vulnerability & Patch Management, Change Management, Access Control, Cryptography, Secure Development (SSDLC), Incident Response, Vendor Risk Management, Business Continuity. Controls include WAF, DDoS protection, network segmentation, IDS/IPS, vulnerability scanning, annual third-party penetration testing, 24×7 SIEM monitoring. Policies are reviewed annually by the CISO and approved by senior management.

Yuno complies with GDPR (EU), LGPD (Brazil), Law 1581 (Colombia), LFPDPPP (Mexico), PDPA (Singapore), and US state privacy laws. ISO/IEC 27701 certified.

1.Data retention & disposal — Retention aligned to contractual, tax, and regulatory obligations; card data retained only as long as tokens are active. Disposal via cryptographic key destruction and secure deletion.

2.Data breach policy — Formal Incident Response Policy (part of ISMS). Breach notification to affected merchants within 72 hours of confirmed breach (aligned with GDPR Article 33). Regulatory notification as applicable.

3.Cross-border data sharing — Cross-border transfers governed by EU Standard Contractual Clauses (SCCs) and AWS's Global Data Processing Addendum; Schrems II-compliant via technical supplementary measures (encryption in transit + at rest, tokenisation of sensitive fields, network segmentation).

4.Data storage and hosting — Personal data hosted in AWS [region to be confirmed per J.3]. DPAs executed per GDPR Art. 28. Sub-processors: primarily AWS; plus a small set of operational sub-processors disclosed in the DPA. Safeguards: SCCs + DPA + tokenisation + AES-256 encryption + HSM key management + network segmentation + access restriction.

Yuno tracks local mandate changes through (a) the local Integrations team in each market, (b) the in-market legal counsel network (Singapore, Colombia, Brazil, Mexico, Qatar, KSA, Turkey, and others), (c) direct engagement with Visa, Mastercard, American Express, JCB mandate programmes, and (d) industry bodies (including Singapore Fintech Association and Emerging Payment Association Asia).

Typical implementation timelines:

• Card-scheme mandate (e.g. 3DS v2.3, Network Token mandates): within the scheme's published compliance deadline — typically implemented 60–90 days before the mandatory deadline to allow merchant testing
• Local regulatory mandate (e.g. Thai PromptPay rules, Indonesian BI payment regulations): 60–120 days depending on complexity
• Impact assessments are produced for each new mandate and shared with affected merchants
• Examples of recent deliveries: UPI Autopay (live via BillDesk), PIX Automático (in progress), Peru 3DS for Redeban (delivered Q1 2026), Visa Intelligent Commerce (ICC) agentic commerce pilot (roadmap)

Traveloka receives advance notice via the KAM and via the Dashboard banner for any mandate that affects merchant routing.

Contracting structure proposed for Traveloka:

• Master Services Agreement (MSA) — between Traveloka Pte. Ltd. and Yuno Singapore as the single operating contract. This aligns with the NDA framework under Yuno Singapore per Traveloka's stated preference.
• Data Processing Addendum (DPA) — covers personal data processing under applicable privacy laws.
• Order Form(s) — per product set / geography, priced per the commercial proposal.
• Security Schedule — referencing Yuno's PCI DSS AOC, SOC 2 Type II, and ISO 27001 certifications.
• Service Level Addendum — SLAs per I.5 / I.8 with service-credit mechanism.

Responsibility allocation:

• Yuno — orchestration platform, SDK, dashboard, tokenisation, routing, retries, reconciliations, fraud layer, network token provisioning, TAM / KAM support.
• Traveloka — merchant onboarding with each selected PSP (since Yuno does not hold funds), KYC / AML with PSPs, end-customer UX.
• Downstream PSP / acquirer — card settlement, dispute arbitration with card networks, regulatory reporting as acquirer, scheme compliance.

Yuno's support team owns end-to-end case management from Traveloka's perspective regardless of which third party is involved.

Yuno's standard liability framework (representative — final wording to be negotiated in the MSA):

• Cap: aggregate liability capped at 12-month fees paid or payable under the MSA, subject to Traveloka's negotiation.
• Uncapped items: breach of confidentiality, IP infringement indemnity, data breach attributable solely to Yuno's gross negligence or wilful misconduct.
• Excluded losses: indirect, consequential, loss of profit, loss of business opportunity (standard).
• Joint or several: where multiple PSPs are involved, Yuno's liability is several and limited to its own acts/omissions; however Yuno commits to coordinate end-to-end as single point of contact.
• Yuno is not liable for PSP failures, issuer declines, or card-network outages.

Yuno's standard indemnities (representative — to be confirmed in MSA):

• IP infringement (third-party claim that the Yuno platform infringes IP)
• Breach of confidentiality by Yuno or its employees
• Data breach resulting from Yuno's negligence
• Regulatory fines caused by Yuno's material non-compliance with its PCI DSS / ISO 27001 obligations

Merchant-side indemnities typically cover: merchant's own breach, merchant content and products, merchant fraud / misconduct.

Any indemnity beyond the standard set will be sized against the liability cap and reviewed in MSA negotiation.

Standard termination triggers (to be finalised in MSA):

• Material breach uncured for 30 days after written notice
• Insolvency / bankruptcy
• Repeated non-payment after written demand
• Regulatory order or law change making performance illegal
• Material security incident breaching contractual controls (with 15-day cure for remediable items)
• Termination for convenience: 90 days' written notice (to be agreed)

Cure period: 30 days standard, 15 days for security-related breaches.
Consultation: parties are required to meet in good faith before termination.
Data portability: Traveloka retains data-portability rights (vault export, transaction archive) for 12 months post-termination.

Function-by-function breakdown of Yuno-PSP responsibilities:

• Refunds — Yuno provides the refund API and routes the refund to the original PSP. Refund liability (availability of funds) sits with the PSP. Yuno provides retry orchestration, status tracking, and reconciliation.
• Fraud management — Yuno provides pre- and post-auth fraud tools; fraud liability ultimately sits with Traveloka (as merchant of record) and is mitigated via Yuno's fraud tools plus 3DS liability shift where applicable.
• Chargebacks — Yuno provides the management platform and evidence orchestration. Financial liability rests with Traveloka per card-scheme rules. PSPs handle the actual scheme communication.
• Settlement — Yuno never holds funds. Settlement flows directly from PSP to Traveloka's bank account.
• Scheme compliance — Yuno implements scheme rules at the orchestration layer; PSPs hold acquirer-level scheme obligations; Traveloka maintains merchant-level scheme obligations.

Yuno has technical integration agreements with PSPs for API access; Traveloka maintains direct commercial agreements with PSPs. This ensures: Traveloka controls PSP selection and terms; no PSP lock-in; PSP fees flow at cost; Traveloka can add or remove PSPs independently.

Adding a new PSP to Traveloka's routing stack typically involves:

1.Yuno confirms the PSP is already in its network, or begins the PSP-onboarding process (~4–8 weeks if new). Yuno signs its own technical / commercial agreement with the PSP.

2.Traveloka signs a direct merchant agreement with the PSP (the PSP is the acquirer holding funds). Yuno's team assists with introductions and onboarding coordination.

3.PSP conducts its own KYB / underwriting on Traveloka.

4.Traveloka configures the PSP credentials in Yuno Dashboard → Connections.

5.Sandbox certification — guided by Yuno through the Yuno Testing Gateway and PSP sandbox.

6.Production certification with the PSP.

7.Go-live — transactions routed through the new PSP per routing rules.

Regulatory / licensing: verified during Yuno's TPRM due-diligence; PSP must hold a valid local licence for the activity in question. Merchant-requested integrations are prioritised.

From Traveloka's side the process is:

• Sign the MSA with the new PSP directly (terms and pricing negotiated bilaterally between Traveloka and the PSP). Yuno can assist with introduction and term-sheet comparison.
• Provide the KYB pack the PSP requires (corp docs, directors, beneficial ownership, expected volumes).
• Configure credentials in Yuno Dashboard → Connections — no code change required.
• Test via Yuno sandbox.
• Agree routing percentage / conditions with the Yuno KAM.

If the PSP is already connected to Yuno: as little as 1–2 business days for configuration and testing.
If the PSP is new to Yuno: 4–8 weeks for connector build plus Traveloka's own PSP onboarding.

Contract structure: bilateral (Traveloka ↔ PSP) plus the MSA (Traveloka ↔ Yuno). Tripartite contracts are not required in most cases. Where a PSP insists on a tripartite governance arrangement, Yuno can accommodate via a side letter.

Changes to routing once the PSP is live: fully self-service in the Dashboard by Traveloka's authorised users. Yuno recommends A/B testing before moving full traffic.

Common blockers Yuno sees and mitigates proactively:

• PSP's own KYB / underwriting backlog — worst-case 6–8 weeks. Mitigation: KYB started in parallel with commercial negotiation.
• Local licensing restrictions (e.g. a PSP only licensed for domestic transactions in a given currency). Mitigation: Yuno's TPRM due-diligence identifies this upfront.
• Scheme certification requirements for new integrations (Visa / Mastercard product certification on specific flows). Mitigation: Yuno holds master certification on most flows; Traveloka inherits scope.
• Technical differences (e.g. PSP-only embedded 3DS vs standalone) which limit retry flexibility. Mitigation: Yuno identifies upfront and negotiates standalone 3DS support with the PSP where possible.
• Settlement currency mismatch (PSP can process currency X but only settle in currency Y). Mitigation: Yuno's TPRM identifies this and documents FX treatment in the Order Form.
• API feature gaps (missing network tokenisation, 3DS 2.x, specific payment methods). Mitigation: evaluated during TPRM; alternative connectors offered as interim.
• Reporting format differences — rare; solved via Yuno's normalisation layer.
• Commercial / capacity — PSPs not accepting new merchants, or terms unacceptable to Traveloka.

Yuno communicates constraints proactively and offers alternative connectors as interim solutions where available.