Case Study · Confidential global B2B SaaS
How UnlockLive shipped a production-grade Airwallex payments and subscription stack on Python and FastAPI — five currencies live in 12 weeks, 99.99% webhook delivery, PCI-DSS-aligned, and a 65% drop in failed-payment churn.
A B2B SaaS expanding from North America into APAC and EMEA needed a payment infrastructure that could collect in five currencies, run subscription billing, handle retries gracefully, and survive a security review. They had outgrown a single-processor setup — FX margins were eating 1.8% of revenue, settlement was multi-day, and their existing webhook handler dropped events under load. The CFO wanted Airwallex for the FX and global rails; the CTO wanted to keep their existing FastAPI stack and not turn payments into a separate service the team couldn't operate.
The ask: ship a production Airwallex integration on FastAPI + PostgreSQL inside a single quarter, with bullet-proof webhook reliability, real subscription state machine, PCI-DSS-aligned architecture, and a clean operations story so the on-call engineer at 2am isn't paging the CTO.
We built a focused Airwallex integration around three engineering ideas: a typed payment domain model, an outbox-pattern webhook pipeline, and a state machine for the subscription lifecycle that the rest of the app can read but only payments code can write.
On the API side, all card data is collected with Airwallex's hosted payment elements so the application backend never touches a PAN — the PCI scope stays at SAQ A. The FastAPI service exposes a small, typed payments API (Pydantic v2 models, OpenAPI documented) that the product team consumes; Airwallex API calls are wrapped in a single client with idempotency keys, exponential retries, and circuit breaking.
On the webhook side, every Airwallex event lands in a signed-and-verified endpoint that does one thing: persist the raw event into an `inbox` table inside a single transaction. A separate worker processes the inbox in order, with at-least-once delivery and idempotent handlers. This pattern alone fixed the dropped-event problem completely — even during a 4x traffic spike at launch.
The subscription state machine handles trial, active, past-due, dunning, paused, canceled, and reactivated, with explicit allowed transitions and an audit log on every state change. Failed payments now run a smart retry schedule (not the default exponential backoff) tuned to the customer's billing-day patterns, which is what produced the 65% drop in failed-payment churn.
We mapped the existing checkout, subscription, dunning, and refund flows; documented every place that touched money or card data; and produced a one-page PCI scoping document that defined exactly which surfaces would stay in SAQ A. We also ran the FX numbers across the planned currency mix to confirm the Airwallex business case before a single line of code was written.
We designed a typed payments domain (Pydantic v2 + a small repository pattern), the inbox/outbox webhook pipeline, the subscription state machine, and the idempotency contract for the Airwallex client. Every external call gets an idempotency key derived from the business event, so a retry can never create a duplicate charge.
We shipped one currency and one subscription flow at a time behind feature flags, starting with the lowest-risk new market. Every webhook handler shipped with a replay test — we'd capture real Airwallex sandbox events, then prove the handler stayed correct under reordering, duplication, and partial failure.
Before go-live we walked the security reviewer through the PCI scope and the threat model, deployed Datadog dashboards for webhook lag, retry rate, dunning funnel, and FX exposure, and wrote a real on-call playbook that an engineer can follow at 2am without paging the lead. We stayed on retainer for 8 weeks of post-launch tuning.
“We went from a single-processor setup that dropped webhooks under load to an Airwallex integration our finance team trusts and our security reviewer signed off on the first time. The dunning rebuild paid for the project on its own.”
Use the inbox pattern. The HTTP endpoint does exactly two things: verify the Airwallex signature and persist the raw event into a database table inside a single transaction. A separate worker drains the table in order, with at-least-once delivery and idempotent handlers. This separation means a slow handler, a deploy, or a downstream outage can never cause you to drop or double-process a webhook.
Collect all card data with Airwallex's hosted payment elements (or their Drop-in / Hosted Payment Page). Your backend only ever sees Airwallex IDs and tokens, never a PAN, CVV, or expiry. We document this scope in a one-page PCI scoping note your security reviewer can sign off on, then we put guardrails in code so a future engineer can't accidentally take card data into the backend.
Yes — FastAPI's async model is excellent for the I/O-bound nature of payment APIs. The reliability comes from the patterns around it: idempotency keys on every Airwallex call, the inbox pattern for webhooks, a circuit breaker for the Airwallex client, and a real subscription state machine. We've shipped FastAPI payment stacks running tens of thousands of charges per day with five-nines webhook delivery.
Airwallex tends to win for businesses collecting in 4+ currencies because of better FX margins and faster cross-border settlement. Stripe usually wins for North America-only SaaS that values its much larger third-party ecosystem. We integrate both and have helped clients run them side by side per-region — the integration patterns we use (typed domain, inbox webhooks, state machine) are processor-agnostic.
10-16 weeks for a production-grade integration covering checkout, subscriptions, webhooks, dunning, refunds, and reporting on a single currency and product. Each additional currency or subscription flow after that usually adds 1-2 weeks. We work in tight slices behind feature flags so you can launch the first currency before the second is complete.
SaaS8x p95 latency drop on hot endpoints (1.8s → 220ms)How we re-architected a hot Python/FastAPI API with a multi-tier Redis caching layer to take p95 latency from 1.8s to 220ms while cutting PostgreSQL load by 70% for a North American B2B SaaS.
Education50K+ Daily Canvas API calls — comfortably inside the university's quotaHow UnlockLive replaced a fragile nightly Canvas LMS sync with an event-driven Python and FastAPI integration that handles 50K+ daily API calls, zero rate-limit incidents, and a 90% smaller sync window — without breaking a single downstream system.
Beauty / Studio-Operations SaaS12+ hrs Saved per month on commission reconciliationHow UnlockLive merged three disconnected tools — calendar bookings, in-studio POS, and a commission spreadsheet — into a single end-to-end SaaS for a US permanent-makeup studio. Public booking with Stripe deposit, in-studio Stripe payment, automated artist-earning splits via Stripe Connect, owner financial dashboard, artist self-serve earnings portal — saving 12+ hours per month on reconciliation and eliminating earnings disputes since launch.
Talk to the same team that built Multi-Currency Payments & Subscriptions on FastAPI + Airwallex for a Global B2B SaaS. We’ll scope your project, give you a fixed-price proposal, and show you the closest analog from our portfolio.
Book a strategy callUnlockLive IT Limited provides state-of-the-art software solutions to clients all over the world. We are a creative force with strategic alliances distributed around the globe
Copyright© UnlockLive .All right reserved 2008 - 2026