API integration for Stripe
We build your Stripe connector
We wire the Stripe API into your product to the Stripe API to take payments, pay out your sellers, bill your subscriptions and open access at the right moment.
- Senior product team
- payment integrations in production
- from scoping to monitoring
What does the Stripe API do and what changes once payment is integrated?
Stripe is the reference payment platform for startups, SaaS companies and marketplaces. Its integration lets your application collect a payment, manage subscriptions with free trials and plan changes, and pay out commissions to third-party sellers if you run a platform. Each payment event: success, failure, refund, dispute, triggers a webhook that your application receives and processes. Payment collection and invoicing become functions of your product, driven by events, rather than tasks handled separately in an admin panel.
What our clients build on the Stripe API
Marketplace with a platform fee
A buyer pays for an order holding items from several sellers. The split and the platform fee happen as the payment goes through, not at the end of the month.
SaaS subscriptions with tiers and trials
Prorated plan changes, trial periods, multi-phase schedules. The homemade proration logic disappears, and with it the costliest class of bugs in a SaaS.
Access provisioning driven by billing
Product rights follow the subscription state instead of a flag maintained by hand in two systems. An unpaid invoice restricts access, a payment reopens it.
Dunning wired into the product
Falling into arrears triggers an in-app message, then a reminder, then a restriction. The sequence is measurable instead of being sent by hand.
What it changes in your business model
Engineering in service of a measurable outcome: payments that do not go missing, accurate billing, fewer unpaid invoices.
Your fee moves with the money
The platform takes its share as the payment goes through. No more invoicing sellers after the fact, no more risk of not collecting your own commission.
You bill the right amount
Proration, tiers and trial endings are computed by Stripe and tested before go-live. Credit notes and apologetic gestures become rare.
No unpaid invoice slips through
Every payment failure surfaces in your product with a defined sequence of actions. You know what is owed, by whom, and for how long.
Accounting that adds up
Payments, fees and payouts are reconciled with your invoices. Your accountant stops rebuilding the flows from an export.
How we ship your Stripe connector
Scoping
Which flow model, who bears disputes, who pays the fees, which events matter. We settle the risk question before writing a line of code.
Development
Typed connector, idempotency keys derived from business intent, retry queue, pinned API version. A demo every week.
Testing
Trial ending, payment failure on renewal, plan change, 3DS authentication: every scenario is replayed with test clocks before the switch.
Monitoring
Alerts on unprocessed events, a payment log, a connector health dashboard. You know a flow is broken before your customers do.
What the Stripe API allows
- Payments and platform fees
- A payment created on your account or on the seller's, with the platform fee taken along the way. That choice decides who bears refunds and disputes.
- Connected accounts and payouts
- Creating seller accounts, collecting verification documents, transferring to their balance and reversing a transfer when an order is cancelled.
- Subscriptions and invoices
- The full life cycle: trialing, active, past due, canceled, paused. Invoices created, finalised and paid, with phased schedules and prorated changes.
- Events and access rights
- Webhooks on subscription creation, trial ending and payment failure, plus entitlements that open and close the features of your product.
The vocabulary of the Stripe API
- application_fee_amount
- The amount your platform keeps on a payment collected for a seller. This is the line that turns Connect into a business model rather than a feature.
- on_behalf_of
- The parameter that makes the connected account the business of record for a payment: settlement country, pricing, statement descriptor on the customer's bank statement.
- Idempotency-Key
- The header that guarantees a replayed instruction does not create a second payment. Stripe stores the status and body of the first response, including server errors.
- past_due
- The status of a subscription whose invoice has not been paid. It is the tipping point between reminder and access restriction, and it has to be wired into your product.
- Entitlement
- An access right derived from billing state. An update event signals that a customer's feature scope has changed, with no flag maintained by hand.
- Pinned API version
- An event is frozen in the version in force when it happened. Major releases are named, the current version is 2026-07-29.dahlia, and a webhook endpoint can be pinned separately.
The real constraints of the Stripe API
invoice.created holds up the whole collection cycle
This event is blocking: without a positive response from your server, finalisation of automatically collected invoices is pushed back by up to 72 hours. A broken webhook delays billing for the whole customer base, not for one account.
Events arrive out of order and more than once
Stripe guarantees no delivery order, and duplicates are expected. A state machine that assumes a sequence is wrong by construction: you have to deduplicate and re-read the object when an event arrives early.
Three tiers of limits, plus a read quota
A hundred requests per second in live mode, caps specific to Billing per subscription, and a separate read quota measured over a rolling thirty days. A background job that re-reads the whole catalogue nightly falls outside that budget.
The Connect flow type is a risk decision
Depending on the model, refunds and disputes are debited from the seller's balance or from yours. It is not a technical choice, it is a line in your income statement, and it gets settled during scoping.
Direct charges or separate transfers?
Two ways to move money between your sellers and you. The right one depends on who has to appear as the merchant, not on the technology.
| Criterion | Direct chargesThe seller collects | Separate transfersThe platform collects |
|---|---|---|
| Who appears on the statement | The seller | Your platform |
| Who bears refunds and disputes | The seller's balance | The platform balance |
| Multi-seller basket | One payment per seller | One payment, several payouts |
| Platform fee | Taken on the payment | Withheld from the amount paid out |
| Requirement on the seller | Card payments capability enabled | Connected account able to receive transfers |
| Undoing it | Refund from the seller's balance | Transfer reversal, if the balance allows |
| The right case | The seller is the merchant | Multi-seller basket, fee taken as money moves |
The choice is made during scoping, with your finance leadership, because it shifts risk from one balance sheet to the other. Changing it later costs a full rework of the flows.
What we measure on a Stripe integration
The other payment APIs
If Stripe is not the right fit for your model, these options are worth discussing during scoping.
StripeWe build your Stripe connectorThis page
PayPalA payment method your buyers already know, often used alongside another.
SumUpCollecting payment in person, when the sale closes out in the field.
GoCardlessRecurring SEPA direct debit, cheaper than cards on high-value amounts.
MollieWe build your Mollie connectorWe combine Stripe with
The stack that surrounds Stripe on our projects.
Stripe integration: your questions
Three steps. First, choose the flow model: a plain payment, a subscription, or Connect with payouts to sellers. Then build the connector server-side, with an idempotency key derived from business intent on every creation, so that a replay never produces a second payment. Finally, handle the webhooks properly: verify the signature against the raw request body, respond immediately, and do the work in a queue. The sensitive part is not the API call, it is the retry logic and the fact that events arrive out of order and sometimes twice.
It mostly depends on the flow model and on how your sellers are onboarded. A plain payment with a fixed fee costs far less than a marketplace with multi-seller baskets, deferred payouts, partial cancellations and verification document collection. The difficulty is almost never the payment call, it is the edge cases: an order cancelled after payout, a seller whose balance is short, a dispute opened two months later. We scope the perimeter up front and give a firm estimate before starting.
They are two products answering two different questions, and many projects need both. Connect answers how to move money between several parties: it is the product for marketplaces and for platforms that take a commission. Billing answers how to charge over time: it is the product for subscriptions, tiers, free trials and proration. A SaaS platform that lets its customers collect payment from their own customers while charging them a monthly subscription uses both, with a data model that has to account for both from the scoping phase onwards.
By treating the handler as an acknowledgement, not as business logic. It verifies the signature against the raw request body, records the event, responds immediately, and lets a queue do the work. There are two reasons for this. The first is that some events are blocking: without a positive response, finalisation of automatically collected invoices is pushed back by up to 72 hours. The second is that duplicates are expected and delivery order is not guaranteed, so deduplication and re-reading the object concerned are essential. Redirects on the receiving URL count as failures.
Yes, and it is a frequent request. Pennylane natively matches Stripe payments from the payment reference, which removes manual matching on that flow. For other accounting software, we build the flow that pushes payments, fees and payouts with the right breakdown, then a periodic consistency check between what Stripe exposes and what your accounting records, with an alert on any gap rather than a silent correction. An accounting entry does not get repaired behind the accountant's back.
A Stripe integration project?
Let's talk. 30 minutes to scope your flow model, check what the API actually allows and tell you honestly what is feasible.
Discuss my Stripe project