Payment Solutions

Depends on your integration pattern. Hosted payment pages (cardholder data never touches your servers) reduce PCI scope to SAQ-A — minimal compliance burden. Direct API where you handle the card data requires SAQ-D and a full PCI audit. We default to hosted pages unless there's a specific UX or product reason for Direct API, which keeps compliance overhead manageable for most mid-market businesses.

Every successful capture should trigger a ZATCA-compliant e-invoice in real time — that's a hard requirement once you're past Phase 2 wave eligibility. We wire the integration so the gateway's webhook fires the ZATCA clearance call on success, the QR-coded invoice gets emailed to the customer + stored as the legal document, and the merchant gets a reconciled view of payments + ZATCA-cleared invoices side by side. See our ZATCA service for the full flow.

We integrate them the same way as cards — hosted checkout flow with webhook-driven settlement. The interesting work is on the merchant side: BNPL has different reconciliation rhythms (settlement T+1 to T+30 depending on installment plan), partial-refund flows are method-specific, and chargeback rates / fraud profiles differ from card. We build the reconciliation tooling that makes BNPL operationally manageable, not just technically integrated.

Probably. We've shipped systems handling thousands of transactions per minute on AWS with autoscaling + Redis-backed idempotency. The architecture pattern matters more than raw infra — we use queue-based capture flows, circuit breakers around gateways, and per-tenant rate limits to prevent one merchant's flash sale from degrading another's checkout. Tell us your peak TPS and we'll be honest about whether we're a fit.