Seraya Psikologi — Documentation

Booking and payment MVP · Implementation baseline · 96 ADR

57. Launch with One Payment Gateway Behind an Adapter

Status

Accepted for launch planning; Midtrans + Snap is selected by ADR 0068 and the initial method categories are QRIS + bank transfer/Virtual Account by ADR 0069. Exact activated method set, merchant eligibility, gateway limits, method-specific refund coverage/fees, and reconciliation cadence remain pre-launch verification items.

Context

Supporting multiple gateways at launch multiplies PaymentEvent verification, refund behavior, failure modes, and reconciliation. The domain already separates Payment, PaymentEvent, and RefundAction from provider details, so a second provider can be added later without making it a launch requirement.

Decision

Launch with Midtrans as the single gateway-of-record and Snap as the initial hosted checkout behind an internal PaymentGatewayAdapter boundary (ADR 0068). The adapter maps create-intent, verify webhook/event, expire/cancel, refund, and reconciliation operations to provider-neutral PaymentEvent/RefundAction state. Domain records never depend on provider-specific status names or redirect assumptions.

Manual/WhatsApp fallback may exist as a support path but is not an automated second payment source in MVP.

Consequences

Positive:

Costs and constraints:

Open follow-up

Verify exact Midtrans QRIS and bank transfer/VA method codes, merchant onboarding, limits, fees, refund coverage, webhook payloads, retry/dead-letter handling, and reconciliation cadence. Provider-of-record, Snap checkout surface, and launch method categories are resolved by ADR 0068/0069.