Stripe payments that match what your app grants

Payment bugs rarely live in the checkout screen. They usually live in the webhook handler that was written once, tested once, and never saw a retry, a duplicate or an event arriving out of order.

In live mode, if your webhook endpoint does not respond properly, Stripe keeps retrying the event for up to three days with exponential back-off. Stripe does not guarantee the order of events, and the same event can arrive more than once. A handler that grants access twice, or cancels a subscription because the "deleted" event arrived before the "paid" one, is a real support ticket.

We verify the Stripe-Signature header against the raw request body, record processed event IDs so duplicates are ignored, and make each handler safe to run again. Outgoing calls use idempotency keys: Stripe accepts them on all POST requests and saves the first result for a key, including errors, so a network retry never charges a card twice.

If you sell to cardholders in Europe, some payments will ask for extra authentication. Stripe’s SCA-ready products handle the challenge, but the app still has to handle the states around it: a subscription that starts as incomplete, a payment that requires action, and off-session renewals that need a saved mandate. We build those paths and test them with Stripe’s test cards before launch.

Stripe describes Connect as the product for platforms and marketplaces that move money between multiple parties. The design decision that matters most is the charge type. Destination charges suit most marketplaces: the platform takes the charge and transfers funds to the seller, and it also carries refunds and disputes. Separate charges and transfers let one payment be split across several sellers or charged before the seller is known, at the cost of more bookkeeping. Direct charges put the seller in front of the customer and move refunds and chargebacks to their balance.

Around that sit onboarding and identity verification for connected accounts, platform fees, payout schedules, and what the app shows a seller whose account is restricted. We choose the setup that matches who carries the risk in your business, not the one that is fastest to wire up.

Apps that sell subscriptions on the web and inside the mobile apps end up with three sources of truth. Apple’s guidelines require in-app purchase to unlock features or functionality such as subscriptions inside the app, while US storefront apps may now link out to other purchase methods. Either way, one user can hold a web subscription from Stripe and a store subscription on their phone.

We model a single entitlement per user on the backend, fed by Stripe webhooks and the store server notifications, with clear rules for overlaps, upgrades, refunds and cancellations. The app asks the backend what the user can access; it never decides that from a local receipt alone.