Activa · payments infrastructure proposal
Activa's first customer is a Bangkok destination where multiple tenant operators — bars, restaurants, wellness studios — share one property. Payments must cover event tickets, recurring memberships, stored-credit wallets, POS at the counter, and the hard requirement: each operator business gets its own payout. This doc maps the Thai landscape as of September 2026, compares every serious provider on verified fees, and lands on an MVP stack plus a scale path. Every fee below carries a source or an explicit not verified tag; fees quoted exclude Thailand's 7% VAT on gateway fees unless noted.
The five payment jobs
One-off charges, spiky nightlife volume, refunds. QR-first at Thai price sensitivity.
Monthly/yearly plans. Needs card-on-file recurring — PromptPay cannot auto-recur.
Stored credit / loyalty balance spendable across the destination. Regulatory tripwire (see risks).
Counter payments: dynamic PromptPay QR on screen + card-present via bank EDC terminals.
The hard requirement. Every tenant operator is its own legal entity and needs its own settlement.
Market reality
Three structural facts shape every choice below. First: PromptPay QR is the dominant consumer rail — real-time, free for the consumer, and priced to merchants at 0–1.65% depending on channel, versus 3.2–3.65% for cards. Whoever routes local traffic to QR wins the margin war. Second: PromptPay is a push payment — the customer scans and approves each time — so recurring memberships must ride on tokenized cards (or QR re-prompts). Third: anyone who holds other businesses' money in Thailand walks into Bank of Thailand licensing territory under the Payment Systems Act — so the split-settlement design must keep Activa out of the funds flow, or ride a provider's licensed sub-merchant machinery.
Contender 1 of 6
Read: the only Thai-native provider with a published price card, a real subscriptions API, and a documented sub-merchant model. The 1.65% PromptPay + ฿10 mobile-banking rails map exactly onto tickets and POS. The open question is purely the Account Chaining beta — access and pricing need one email to confirm.
Contender 2 of 6
Read: Connect direct charges (tenant = connected account, Activa takes an application fee) is a legitimate split architecture in Thailand — the model Setpoint already knows. But no Terminal, no daily payouts, restricted Connect modes, and 4.75% on the tourist cards a Bangkok nightlife destination will see plenty of. Strong runner-up; wrong first pick for this venue profile.
Contender 3 of 6
Read: 1.8% cards and free PromptPay is roughly half of Opn's card rate — real money at F&B volume. Beam is the negotiating lever and a credible secondary rail for POS QR, but the multi-tenant payout and subscriptions machinery is unproven. Get a call with them; don't build the platform spine on it yet.
Contender 4 of 6
Read: the only contender whose split-payment product is the headline, running on a Thai license. If Opn's Account Chaining beta disappoints, this is the platform-payments fallback — at the cost of murkier public pricing and a request-to-activate process.
Contenders 5 & 6
KBank K-Payment / SCB gateways: negotiated MDR ~2.5–3.5% with setup + monthly fees and slower onboarding (~3 weeks at KBank) secondary sources. Their real value is elsewhere: bank open APIs for dynamic PromptPay QR (create QR, webhook confirmation, status query, refunds) at bank-negotiated QR rates — often the cheapest QR rail in the market — plus EDC terminals for card-present at the F&B counters, which no gateway above solves (Stripe Terminal absent; Opn/Beam are online-first). One bank relationship is part of the stack regardless.
Ruled out for MVP
Side by side
| Provider | Domestic cards | PromptPay QR | Cross-border cards | Settlement | Recurring | Split / sub-merchant payouts | Entity req. | DX / PCI |
|---|---|---|---|---|---|---|---|---|
| Opn (Omise) | 3.65% +VAT | 1.65% | 3.65% (same card rate; multi-currency addable) | ~7-day hold, then custom auto-payout schedule; ฿20/transfer | Yes — Schedules API | Yes — Account Chaining + Chains API (beta, enable via support; each tenant = own Opn account & payout) | Thai co. + Thai bank acct | Good docs, official libs; tokenized = low PCI scope |
| Stripe TH | 3.65% + ฿10 | 1.65% | 4.75% + ฿10 +2% FX | Biweekly/weekly/monthly payouts (no daily listed) | Yes — Billing (+0.7%) | Partial — Connect direct charges TH→TH only; no separate charges & transfers, no top-ups | Thai-registered business | Best-in-class; Elements = minimal PCI. No Terminal in TH |
| Beam | 1.80% | from 0% | 3.25% (overseas cards) | T+1 daily (QR payout T+3) | Charges API (depth unverified) | "Payouts to multiple accounts" on pricing page — no documented marketplace product verify | Thai merchant onboarding inferred | Modern API, PCI DSS certified; young company |
| Xendit / GB Prime Pay | 3.2% (form) | 0.8% (form) vs 2.5%+฿7 (Xendit page) — conflicting | Amex 3.5%; intl terms by quote | Negotiated; ฿20 fee on settlements <฿50k | Yes — recurring + tokenization | Yes — xenPlatform sub-accounts + split rules (TH: activate by request) | Thai co. via GBPP | Regional-standard docs |
| 2C2P | Quote only | Quote only | Strong (SEA + cross-border focus) | Negotiated, rail-specific | Yes — with retry logic | Yes — marketplace suite (sub-merchant onboarding, disbursements) | Enterprise contract | Enterprise-grade; heavier integration |
| Bank gateways (KBank/SCB) | ~2.5–3.5% negotiated secondary | Bank-negotiated, market's lowest QR rates | Via bank acquiring | Bank-cycle; EDC next-day typical not verified | Limited / bespoke | No platform product — one merchant per contract | Thai co., setup + monthly fees, ~3-wk approval | Open APIs for QR exist; legacy DX otherwise. EDC solves card-present |
All percentage fees exclude 7% VAT charged on the fee itself. "Quote only" = provider publishes no rates; treat every number in this table as an opening position, not a floor — Opn's own pricing page invites volume-based reductions.
The hard requirement
One destination, many operator entities, each needing its own payout. There are exactly three architectures — and the right answer is a sequence, not a choice.
One merchant account per destination org (24 BLVD's entity). Every charge lands there. Activa's ledger attributes each baht to a tenant operator; the org runs weekly payouts from its own bank account against Activa's statement.
Why it works: ships in weeks, zero provider dependency, Activa never holds funds — the destination org does, which it already legally can as the master lessor collecting from its own tenants.
Cost: payouts are manual-ish (bank transfer batch), trust depends on ledger transparency, and it leans on the org's own accounting.
Each tenant operator registers its own account with the provider; Activa routes every charge to the right tenant at creation time and takes a platform fee. Funds settle directly to each operator's bank — Activa and the org never touch them.
Who offers it: Opn Account Chaining (beta), Stripe Connect direct charges (TH→TH), Xendit xenPlatform (activate for TH), 2C2P marketplace suite.
Key simplification: at 24 BLVD nearly every order belongs to ONE operator — so charge-level routing covers ~everything; true single-charge splitting is only needed for mixed baskets and bundles.
Activa aggregates funds itself and disburses to operators — becoming a payment facilitator holding third-party money, which puts it squarely in Bank of Thailand e-payment licensing under the Payment Systems Act.
Why not: capital requirements, compliance burden, and a licence application — for capability the providers in column B already rent out. Only worth revisiting if payments margin becomes Activa's core business model at multi-destination scale.
Recommendation
Risks & open questions