All blueprints
E-commercecomplex complexity

Payment Processing Pipeline

Reference architecture for payment processing covering checkout, webhooks, reconciliation, refunds, and accounting integration.

7

Components

5

Considerations

4

Alternatives

complex

Complexity

Fit

When this blueprint fits

And when to walk away from it

When to use this

Payments are core to the product and you handle enough volume that reconciliation, refunds, and accounting integration need to be reliable not best-effort. Marketplaces, subscription products, and financial services all live here.

When NOT to use this

If your only payment surface is a single Stripe Checkout link and a once-a-month export, the lightweight integration is fine. This blueprint is for teams where payment correctness is part of the product.

Architecture

System components

Key building blocks of this architecture, layered from infrastructure up.

01

Checkout Service

PCI-conscious checkout with hosted fields, 3D Secure support, and saved-card management. Stripe Elements and Adyen Drop-in both keep PCI scope minimal. The checkout UI is where conversion lives, so A/B test relentlessly. See Stripe vs Adyen.
Stripe ElementsAdyen Drop-in3DSApple/Google Pay
02

Webhook Pipeline

Reliable webhook ingestion with retries, signature verification, idempotency, and dead-letter queues. Webhooks are the authoritative source of payment state. Every webhook gets stored before it is processed, processed exactly once via idempotency keys, and retried on failure.
Webhook VerificationQueueIdempotency KeysDLQ
03

Order State Machine

Explicit lifecycle for orders, payments, refunds, and disputes with audit history. Every state transition is logged with the actor (user, system, webhook), timestamp, and previous state. The audit log is your customer support tool and your reconciliation reference.
XStatePostgreSQLAudit LogsEvent Sourcing
04

Reconciliation Service

Match provider payouts against the internal ledger nightly. Differences are inevitable: failed webhooks, manual refunds, currency conversions. The reconciliation job surfaces them within 24 hours instead of months.
CronLedgerBigQuerySlack Alerts
05

Accounting Sync

Push invoices, payouts, and refunds to QuickBooks, NetSuite, or Xero with the correct accounting treatment. Finance teams will hand you a chart of accounts mapping. Follow it precisely and reconcile monthly with the finance lead.
QuickBooks APINetSuiteXeroCustom Mapping
06

Fraud Hooks

Pre-authorisation fraud screening with provider rules plus custom logic. Stripe Radar covers most cases; high-risk products need a dedicated fraud platform layered on top. See the fraud detection blueprint.
Stripe RadarSiftCustom RulesDevice Fingerprinting
07

Refunds and Disputes

Workflow for partial refunds, chargebacks, and dispute evidence submission. Disputes have hard provider deadlines; the system should surface them in a dashboard with everything an ops team needs in one place.
Stripe Disputes APIEvidence WorkflowEmail Alerts

Planning

Critical considerations

The things I have learned the hard way and would not skip on the next build.

Treat webhooks as authoritative. Never trust client-side success messages for state transitions. The user might see a confirmation page while the actual payment failed.
Idempotency is non-negotiable. Every retry must be safe. Use provider-supplied idempotency keys on every API call and dedup webhooks on the storage table before processing.
Build reconciliation reports from day one. The bug you do not catch is the expensive one. A nightly Slack alert with discrepancy counts catches issues before finance does.
Plan for currency, tax, and compliance early. International expansion forces hard architectural decisions; the cleanest answer is multi-currency from day one and tax computed by a dedicated service.
Need a payments partner? Start a project.

Options

Alternative approaches

Where I would consider a different shape entirely, with the trade-offs spelled out.

Alternative 01
Lago or Orb for managed billing and metering when usage-based pricing is the core model.
Alternative 02
Maxio (formerly Chargify/SaaSOptics) for SaaS-specific billing with revenue recognition built in.
Alternative 03
Direct acquirer integration (e.g. Worldpay, Adyen) for very high volume where Stripe fees become material.
Alternative 04
Paddle as a merchant of record for global SaaS that wants tax and compliance handled by the provider.
Need a partner on this?

Need help implementing this blueprint?

I help teams adapt blueprints like this to their specific requirements and ship from planning through production.