Payment gateway integration.

Taking a payment is the easy part; most gateways make that a few lines of code. The work is everything after: the webhook that arrives twice, the card that fails on renewal, the customer who disputes a charge, the refund that needs to reverse an entitlement, and proving at the end of the month that what you were paid matches what you delivered. I have been building payment flows since 2015, when I wrote a Bitcoin settlement gateway before processors offered it as a product.

What’s included

• Stripe integration: one-off payments, subscriptions and invoicing
• Checkout and payment flows built for conversion
• Webhook handling with signature verification and idempotency
• Subscription lifecycle: upgrades, downgrades, dunning and cancellation
• Refunds, partial refunds and entitlement reversal
• Failed and retried payment handling
• Reconciliation reporting so payments match delivery

Idempotency is not optional

Networks retry. Users double-click. Gateways resend webhooks. Without idempotency keys and a record of what you have already processed, you will eventually charge someone twice or grant an entitlement twice. This is one of the cheapest things to get right at build time and one of the most expensive to fix afterwards.

Subscriptions are a state machine

A subscription is not a boolean. It is trialling, active, past due, cancelled but still entitled until period end, or cancelled and revoked. Most billing bugs come from treating that as a single flag. I model the states explicitly and make entitlement checks read from that model rather than from scattered conditionals.

Reconciliation

You should be able to answer, for any period, what you charged, what actually settled, what was refunded and what is disputed — and match it to what your system delivered. I build the reporting for that rather than leaving you to piece it together from a gateway dashboard.