Provider capability matrix

What each payment provider supports across the unified API — capture, refunds, disputes, settlement, and billing mode.

PaymentGateway exposes many payment providers behind one unified API. You integrate once; the platform routes each charge, refund, capture, and webhook to the right provider. Stripe is the reference implementation — every other provider is normalized to behave the same way, and each provider declares exactly which capabilities it supports in its manifest. When a provider does not support a capability, the API rejects that operation up front rather than failing silently.

Legend

Symbol	Meaning
✅	Supported
🟡	Supported, with caveats / hardening in progress
📝	Draft / coming soon — not yet available
➖	Not offered by this provider (by design)

Capture — auto captures funds immediately at charge time; manual authorizes now and lets you capture (or cancel) later. Refund — refund to the original payment source. Disputes — chargeback/dispute events update your internal state. Settlement — delay (in business days) before captured funds are available to you (T+0 = immediate). Billing mode — native means the provider owns invoices/subscriptions; internal means PaymentGateway's billing engine drives them.

Card providers

Provider	Capture	Refund	Disputes	Settlement	Billing mode	Status
Stripe	auto + manual ✅	✅	✅ full lifecycle	T+2	native	✅ Live — reference
Omise	auto + manual ✅	✅	📝 coming soon	T+2	internal	✅ Live ¹
SCB	auto ✅ · manual ➖	➖	➖	T+0	internal	✅ Live ²
KBank	auto ✅ · manual ➖	✅	➖	T+0	internal	✅ Live ²
Lodash	📝	📝	📝	—	internal	📝 Coming soon ³

¹ Omise: capture and refund are live. A few webhook nuances apply — see Webhook events by provider: charge.capture/charge.reverse fire only on the manual-capture path, refunds emit no completion event (state is reconciled on read), and there is no authorization (amount_capturable) event. Dispute handling is in progress. ² SCB and KBank are auto-capture only by design — manual capture is intentionally not offered, so the API rejects it rather than pretending to support it. SCB card has no refund API. KBank card refunds go back to the card: a full refund on the day of payment (before the bank's cut-off) is a void, later it is a refund, and a partial refund needs the charge to be settled first. ³ Lodash is an in-house card processor still in development; all operations currently return "coming soon."

Wallets, BNPL & QR providers

Provider	Method	Capture	Refund	Settlement	Billing mode	Status
Alipay	alipay	auto ✅	✅	T+0	internal	✅ Live
Touch 'n Go	touchngo	auto ✅	✅	T+0	internal	✅ Live
Atome (BNPL)	atome	auto ✅	✅	T+0	internal	✅ Live
GrabPay	grabpay	auto ✅	✅	T+0	internal	✅ Live
PayPal	paypal	auto + manual ✅	✅	T+2	internal	✅ Live
PayPay	paypay	auto ✅	✅	T+0	internal	✅ Live
Rabbit LINE Pay	rabbitlinepay	auto + manual ✅	✅	T+0	internal	✅ Live
ShopeePay	shopeepay	auto ✅	✅	T+0	internal	✅ Live
WeChat Pay	wechat_pay	auto ✅	✅	T+0	internal	✅ Live
PromptPay (SCB / KBank)	promptpay	auto ✅	➖ ⁴	SCB T+2 · KBank T+0	internal	✅ Live
K PLUS	mobile_banking	auto ✅	➖	T+0	internal	✅ Live
SCB EASY	mobile_banking	auto ✅	➖	T+0	internal	✅ Live
International QR (SCB)	qr_cross_border	auto ✅	➖	T+2	internal	✅ Live ⁶
Alipay (SCB)	alipay	auto ✅	➖	T+2	internal	✅ Live ⁶
WeChat Pay (SCB)	wechat_pay	auto ✅	➖	T+2	internal	✅ Live ⁶
Apple Pay	apple_pay	📝	📝	—	internal	📝 Coming soon ⁵
Google Pay	google_pay	📝	📝	—	internal	📝 Coming soon ⁵

⁴ PromptPay and mobile-banking methods are QR/redirect flows that settle on a provider notification; refund-to-source is not currently offered through these methods. ⁵ Apple Pay and Google Pay are scaffolded but await payment-processor wiring.

⁶ The SCB cross-border rails are QR flows a foreign wallet scans. qr_cross_border is one QR that accepts every scheme SCB returns in its channel list; alipay and wechat_pay mint a wallet-specific QR. Refunds are not wired yet, and qr_cross_border settles from the inquiry and expiry sweepers rather than from SCB’s unsigned callback.

Payout providers

Provider	Method	Status
Wise	bank_transfer	✅ Live — payouts only (no charge capability)
Omise (payout)	bank_transfer	🟡 Bank-transfer payouts; transfer-event webhook handling is minimal

How capabilities map to the API

Manual capture — declared per method; when present you may create a charge with capture_method: manual, then capture or cancel it later. Providers that omit it reject manual capture at validation.
Refund to source — declared per method; required for a refund back to the original payment instrument. Providers without it reject refund requests up front.

A refund always goes back to the original payment method; refunding into a customer wallet balance was removed, so there is no fallback. When the provider has no refund API for the method a charge used — for example PromptPay and QR through SCB or KBank, K PLUS, SCB EASY, KBank SmartPay, Krungsri card and KMA, Apple Pay and Google Pay — POST /refunds refuses the refund with E4526 and creates nothing, and the dashboard shows Refund disabled with the reason. Refund those customers outside PaymentGateway. GET /charges/{id}/refund_methods reports this ahead of time as available: false with an unavailable_reason.

Disputes — only providers with dispute support surface chargeback events into your payment state. Where a provider can deliver disputes but handling isn't wired yet, it is marked 📝.
Settlement (T+N) — informational timing for when captured funds become available; absent means T+0.
Billing mode — native (provider owns invoices/quotes/subscriptions) vs internal (PaymentGateway's billing engine). This affects which billing webhooks are authoritative.

For the exact event each provider emits and how it maps to your payment state, see Webhook events by provider.