Subscription Billing and Payment Integration: The Technical Guide to Getting Paid

Revenue is the lifeblood of any software business, and the payment system is the vein through which it flows. Get it right, and money arrives predictably while customers barely think about the billing experience. Get it wrong, and you leak revenue through failed payments, lose customers to confusing checkout flows, and spend engineering cycles fixing billing edge cases instead of building product.

Payment integration sounds straightforward — charge the card, deliver the service. In practice, it’s one of the most detail-intensive areas of software development. Subscription billing adds recurring charges, plan changes, prorations, dunning, tax calculations, and multi-currency support on top of an already complex foundation.

This guide covers the technical decisions and implementation details that determine whether your payment system is a revenue engine or a revenue leak.

The Payment Landscape

The payment industry has evolved significantly. A few trends shape the decisions you’ll make:

• Embedded payments. Customers expect to pay without leaving your application. Redirects to third-party payment pages are increasingly seen as friction.
• Alternative payment methods. Credit cards are no longer the default everywhere. Digital wallets (Apple Pay, Google Pay), bank transfers (SEPA, ACH), and buy-now-pay-later (Klarna, Afterpay) are significant in many markets.
• Regulatory complexity. PSD2 Strong Customer Authentication (SCA) in Europe, PCI DSS updates, and varying tax requirements across jurisdictions add layers of compliance.
• Usage-based billing. The shift from flat subscriptions to consumption-based pricing (API calls, compute hours, storage) adds metering complexity.

Payment Gateway Comparison

Your payment gateway is the intermediary between your application and the financial networks. The choice affects your development experience, feature set, geographic reach, and cost.

Stripe

Position: The developer-first payment platform. Dominant among startups and SaaS companies.

Strengths:

• Best-in-class API design and documentation. Developers can integrate Stripe in hours, not weeks.
• Stripe Billing handles subscription management, invoicing, prorations, and dunning out of the box.
• Global coverage: 135+ currencies, 46+ countries for business accounts.
• Rich ecosystem: Stripe Connect for marketplaces, Stripe Tax for automated tax calculation, Stripe Radar for fraud detection.
• Webhooks are reliable and well-documented.

Limitations:

• Pricing (2.9% + 30 cents per transaction in the US) is higher than negotiated rates available from other providers at volume.
• Account holds and freezes on high-risk businesses with limited recourse.
• Feature richness creates complexity. Stripe’s surface area is vast, and understanding which features to use requires investment.

Best for: SaaS, marketplaces, platforms. The default choice for most software businesses.

Braintree (PayPal)

Position: PayPal’s developer platform. Strong in e-commerce and for businesses that want to offer PayPal alongside card payments.

Strengths:

• Native PayPal integration (including PayPal Credit and Venmo in the US).
• Drop-in UI components that handle the full payment flow.
• Competitive pricing at volume (negotiable rates below Stripe’s standard pricing).
• Strong in the e-commerce space with guest checkout support.

Limitations:

• API and documentation quality below Stripe’s standard.
• Less innovation cadence. Feature releases lag behind Stripe.
• PayPal’s parent company brings both brand recognition and brand baggage.

Best for: E-commerce businesses where PayPal acceptance is important. Businesses processing enough volume to negotiate favorable rates.

Adyen

Position: Enterprise payment platform. Used by Uber, Spotify, McDonald’s, and other large-scale operations.

Strengths:

• Single platform for online, in-store, and mobile payments. True omnichannel.
• Direct connections to card networks (acquiring + processing in one). This reduces intermediaries and can lower costs.
• Revenue optimization features: intelligent routing, network tokenization, and account updater.
• Strong in Europe and Asia-Pacific.

Limitations:

• Not designed for small businesses. Minimum volume requirements and enterprise-oriented pricing.
• Integration is more complex than Stripe. Less self-service, more sales-driven.
• Documentation is adequate but not at Stripe’s level.

Best for: Large businesses processing millions in payment volume. Companies needing omnichannel payment support.

PayPal (Direct)

Position: The most recognized online payment brand globally, with over 430 million active accounts.

Strengths:

• Buyer trust. Many consumers prefer PayPal for purchases from unfamiliar merchants.
• Global reach with local payment methods in many markets.
• Seller protection and dispute resolution.

Limitations:

• Higher fees for international transactions.
• Checkout redirects can reduce conversion rates.
• Developer experience below Stripe and Braintree.

Best for: Adding as a secondary payment method alongside card payments, especially for consumer-facing e-commerce.

Subscription Billing Models

How you charge customers is as important as how you process payments. The billing model must match your product’s value delivery.

Flat-Rate Pricing

A single price for the product. Simple to implement, simple to understand.

Example: $49/month for the full product.

Pros: Easiest to implement, easiest for customers to budget for. Cons: Leaves money on the table with heavy users. May price out lighter users.

Tiered Pricing

Multiple plans at different price points, each with different feature sets or usage limits.

Example: Starter ($29/month, 1 user), Pro ($79/month, 5 users), Enterprise ($199/month, unlimited users).

Pros: Captures different customer segments. Creates a natural upgrade path. Cons: More complex billing logic. Customers may be confused by plan differences. Proration on plan changes adds implementation complexity.

Usage-Based Pricing

Charge based on consumption. Metering tracks usage, and billing applies the pricing model at the end of the billing cycle.

Example: $0.01 per API call. $0.023 per GB of storage per month.

Pros: Aligns cost with value. Low barrier to entry (start free or cheap, pay more as you use more). Cons: Revenue is unpredictable. Customers may worry about surprise bills. Metering infrastructure adds engineering complexity.

Per-Seat Pricing

Charge based on the number of users or seats in the account.

Example: $12/user/month.

Pros: Revenue scales with adoption within an account. Simple to understand. Cons: Discourages adding users (which reduces adoption). Some customers create shared accounts to avoid per-seat charges.

Hybrid Pricing

Combine two or more models. A base platform fee plus usage-based overage, or per-seat pricing with tiered feature access.

Example: $99/month base (includes 10 users and 100K API calls) + $10/additional user + $0.005/additional API call.

Pros: Captures value across multiple dimensions. Predictable base revenue with usage upside. Cons: Most complex to implement and communicate. Requires sophisticated billing engine.

Billing Engine Architecture

A production billing system has several components that work together.

Plan Management

Define and manage your pricing plans, including:

• Plan attributes (price, billing interval, currency, trial period).
• Feature flags tied to plans (which features are available at which tier).
• Plan versioning (existing subscribers stay on their current plan when you change pricing).
• Promotional pricing and coupons.

Most payment gateways (Stripe Billing, Braintree) handle plan management. For complex pricing (especially usage-based or hybrid), you may need a dedicated billing service like Lago, Stigg, or Orb.

Metering

For usage-based billing, you need to track consumption:

• Event ingestion. Capture usage events (API calls, storage, compute) in real time.
• Aggregation. Sum, average, or count usage within billing periods.
• Idempotency. Ensure duplicate events don’t result in double-counting.
• Near real-time reporting. Customers need to see their current usage before the bill arrives.

Build metering as a separate service from billing. Usage events are high-volume and should flow through a pipeline (Kafka, Redis Streams) rather than directly to your billing database.

Invoicing

Generate invoices that include:

• Line items for each charge (subscription, overage, one-time fees).
• Taxes calculated per jurisdiction.
• Credits and discounts applied.
• Payment status and due date.

Invoices must be immutable once generated. If a correction is needed, issue a credit note and a new invoice.

Dunning

Dunning is the process of recovering failed payments. This is where most billing systems lose significant revenue if not handled properly.

PCI DSS Compliance

The Payment Card Industry Data Security Standard (PCI DSS) governs how you handle credit card data. The level of compliance required depends on how you interact with card data.

SAQ Levels

• SAQ A. You never see card data. Payment is handled entirely by a third-party hosted payment page (Stripe Checkout, PayPal buttons). Simplest compliance. 22 requirements.
• SAQ A-EP. Your website controls the payment page but card data goes directly to the payment processor (Stripe Elements, Braintree Drop-in). 191 requirements, but still achievable without a dedicated security team.
• SAQ D. You store, process, or transmit card data on your servers. 300+ requirements. Full PCI audit required. Avoid this unless you have a specific need and a security team.

Tokenization

The standard approach for most applications: the customer’s card data is sent directly to the payment processor (never touches your server), and you receive a token that represents the card. You store the token and use it for future charges.

This keeps you at SAQ A or SAQ A-EP and eliminates the risk and compliance burden of handling raw card numbers.

Hosted Payment Pages vs. Embedded Elements

• Hosted payment pages (Stripe Checkout, PayPal): Redirect the customer to the processor’s page. Simplest PCI compliance (SAQ A). Less control over the experience.
• Embedded elements (Stripe Elements, Braintree Hosted Fields): Card input fields are iframes served by the processor, embedded in your page. Feels native. SAQ A-EP. The recommended approach for most applications.

Practical Recommendation

Use embedded payment elements (Stripe Elements or equivalent). They provide a native-feeling experience while keeping card data off your servers. You get SAQ A-EP compliance, which is manageable without a dedicated security team.

Handling Taxes

Tax calculation on digital goods is one of the most frustrating aspects of payment integration. The rules vary by jurisdiction, change frequently, and carry real penalties for non-compliance.

VAT in the EU

Digital services sold to EU consumers are subject to VAT at the rate of the customer’s country (not the seller’s). Rates range from 17% (Luxembourg) to 27% (Hungary). You must collect proof of the customer’s location (two non-conflicting pieces of evidence: IP address, billing address, bank country).

If you sell below the EU-wide threshold of EUR 10,000 in cross-border digital sales, you can apply your home country rate. Above that, you must register for the One-Stop Shop (OSS) scheme or register for VAT in each member state individually.

Sales Tax in the US

Sales tax on digital goods varies by state, county, and even city. Not all states tax digital goods. Nexus rules (where you have sufficient connection to a state to trigger tax obligations) are complex and were significantly expanded by the 2018 South Dakota v. Wayfair decision.

Tax Automation Tools

Don’t build tax calculation yourself. Use a service:

• Stripe Tax. Integrated with Stripe. Calculates and collects tax in 50+ countries. Simplest if you’re already on Stripe.
• TaxJar. Focused on US sales tax. Automated filing in most states.
• Avalara. Enterprise-grade tax automation. Covers 190+ countries. More complex but more comprehensive.

Practical Recommendation

If you’re on Stripe, start with Stripe Tax. It covers the most common scenarios and requires minimal integration effort. If you need comprehensive global tax compliance or are processing on multiple gateways, use Avalara.

Failed Payment Recovery

Failed payments are the silent killer of subscription revenue. Industry data shows that 5-10% of subscription payments fail each month, and without effective recovery, a significant portion of those customers churn involuntarily.

Why Payments Fail

• Expired cards (most common). The card reached its expiration date.
• Insufficient funds. The customer’s account doesn’t have enough balance.
• Card network issues. Temporary processing failures.
• Bank declines. The issuing bank declined the transaction (fraud suspicion, spending limits, regional blocks).

Dunning Sequences

A dunning sequence is a series of retry attempts and customer communications designed to recover failed payments:

1. Immediate retry. Some failures are transient. Retry immediately or within a few hours.
2. Smart retries. Retry at times when success rates are historically higher (typically mid-week, during business hours in the customer’s timezone).
3. Customer notification. Email the customer when a payment fails. Include a direct link to update their payment method. Don’t make them log in, navigate to settings, and figure out the problem themselves.
4. Escalating urgency. First email is informational. Second email (3-5 days later) warns of potential service interruption. Third email (7-10 days later) is a final notice.
5. Grace period. Continue providing service during the dunning period. Cutting access immediately creates a terrible customer experience and often results in churn rather than recovery.
6. Account pause or downgrade. If retries and emails fail, pause the account or downgrade to a free tier rather than deleting it. Many customers update their payment method within a month.

Recovery Rates

Effective dunning recovers 40-70% of failed payments. Without dunning, most failed payments result in involuntary churn. At $100 average revenue per customer with 1,000 subscribers and a 7% monthly failure rate, the difference between good and no dunning is $33,600-$50,400 in annual recovered revenue.

Stripe handles basic dunning automatically. For more sophisticated recovery, services like Churnkey, Baremetrics Recover, or Dunning handle the sequence management and customer communication.

Multi-Currency and International Payments

If you serve customers globally, currency handling adds complexity.

Settlement Currency vs. Presentment Currency

• Presentment currency: What the customer sees and pays in ($, EUR, GBP).
• Settlement currency: What you receive in your bank account.

Most gateways handle the conversion, but exchange rates include a markup (typically 1-2% above the interbank rate). For significant international volume, consider maintaining bank accounts in multiple currencies to avoid conversion fees.

Pricing Strategy

Two approaches:

1. Dynamic conversion. Set prices in one currency and convert dynamically. Simple but creates odd-looking prices (EUR 47.23 instead of EUR 49).
2. Localized pricing. Set specific prices for each currency/market. Better customer experience but requires managing multiple price points and handling exchange rate fluctuations in your revenue.

Payment Methods by Region

• Europe: SEPA Direct Debit for recurring payments (lower fees than cards), iDEAL (Netherlands), Bancontact (Belgium), Sofort (Germany/Austria).
• Asia: Alipay, WeChat Pay (China), GrabPay (Southeast Asia), Paytm (India).
• Latin America: Boleto Bancario (Brazil), OXXO (Mexico).

Stripe and Adyen support most of these. Offering local payment methods can increase conversion rates by 5-20% in markets where card penetration is lower.

Webhooks and Event-Driven Payment Flows

Payment systems are inherently asynchronous. A charge can succeed, fail, be disputed, or be refunded at any time. Your application must react to these events reliably.

Webhook Architecture

The payment gateway sends HTTP POST requests to your endpoint when events occur (payment succeeded, subscription canceled, dispute opened).

Key implementation requirements:

• Verify signatures. Every webhook request includes a cryptographic signature. Verify it before processing. Without verification, anyone can send fake events to your endpoint.
• Idempotent processing. Webhooks can be delivered more than once. Your handler must produce the same result regardless of how many times it processes the same event. Use the event ID as a deduplication key.
• Respond quickly. Return a 200 status code immediately, then process the event asynchronously. Gateways retry on timeout (typically 5-30 seconds), and slow processing can result in duplicate deliveries.
• Handle out-of-order delivery. Events may arrive in a different order than they occurred. A payment_intent.succeeded event might arrive before or after an invoice.paid event for the same transaction.
• Monitor failures. Alert on webhook processing failures. A stuck webhook queue means customers aren’t getting access, subscriptions aren’t activating, and revenue isn’t being recorded.

Critical Events to Handle

At minimum, your webhook handler must process:

• invoice.paid — Activate or renew the subscription.
• invoice.payment_failed — Trigger dunning sequence.
• customer.subscription.deleted — Revoke access.
• customer.subscription.updated — Handle plan changes.
• charge.dispute.created — Flag the account, gather evidence.
• payment_method.attached — Update payment status after card update.

Testing Payment Integrations

Payment testing requires specific approaches because real financial transactions are involved.

Test Mode

Every major gateway provides a test mode with test card numbers. Use these for development and automated testing:

• Stripe test cards: 4242 4242 4242 4242 (success), 4000 0000 0000 0002 (decline), 4000 0000 0000 3220 (3D Secure required).
• Test specific scenarios: insufficient funds, expired cards, fraud detection triggers, SCA challenges.

Webhook Testing

• Use Stripe CLI or ngrok to receive webhooks in your local development environment.
• Write integration tests that simulate the full webhook flow: event received, processed, database updated, user notified.
• Test failure scenarios: what happens when your webhook endpoint is down? When processing fails? When events arrive out of order?

End-to-End Testing

Before launching, test the full payment lifecycle:

1. New subscription signup.
2. Successful payment.
3. Failed payment and dunning sequence.
4. Plan upgrade and downgrade (with proration).
5. Cancellation (immediate and end-of-period).
6. Reactivation after cancellation.
7. Refund processing.
8. Tax calculation for different jurisdictions.

Common Mistakes

Not Handling Plan Changes Correctly

Upgrading mid-cycle requires proration: charge for the remaining time on the new plan and credit for the unused time on the old plan. Stripe handles this automatically, but if you’re building custom billing logic, proration math is error-prone.

Ignoring Dunning

Relying on a single payment attempt and then canceling the subscription. This silently churns paying customers who would have resolved the payment issue if notified.

Not Providing a Self-Service Payment Update Flow

When a card expires, customers need to update their payment method without contacting support. Make the “update payment method” flow frictionless and accessible from the failed payment email.

Hardcoding Prices

Prices stored in code rather than in the billing system (or a database). This makes A/B testing pricing, offering promotions, and supporting multiple currencies unnecessarily difficult.

Not Testing International Scenarios

Payment flows that work perfectly in the US may fail in Europe (SCA requirements), Asia (different payment methods), or anywhere with VAT obligations.

Storing Card Numbers

Never store raw card numbers in your database. Use tokenization via your payment gateway. This isn’t just a best practice — it’s a PCI DSS requirement, and violations carry fines of $5,000-$100,000 per month.

Putting It Together

When we built the e-commerce payment system for Pakz Studio — a platform that saw a 38% increase in user engagement after launch — the payment integration was a critical technical workstream. The implementation covered multi-method checkout, automated tax handling, and webhook-driven order fulfillment. The lesson from that project applies broadly: payment systems deserve the same engineering rigor as any other critical system, and cutting corners on payment infrastructure creates compounding problems that surface as lost revenue and frustrated customers.

For most SaaS and e-commerce applications, the practical path is:

1. Start with Stripe (or your gateway of choice) using embedded payment elements.
2. Implement Stripe Billing for subscription management if your pricing model fits its capabilities.
3. Build robust webhook handling from day one with idempotency, signature verification, and monitoring.
4. Add Stripe Tax (or an equivalent) before your first international customer.
5. Configure dunning early. Failed payment recovery is too valuable to defer.
6. Test the full lifecycle before launch: signup, payment, failure, recovery, upgrade, downgrade, cancellation, refund.

Payments are infrastructure. Like security and performance, they’re best addressed from the start rather than retrofitted later. The companies that treat payment integration as a first-class engineering problem build systems that reliably turn product value into revenue — and that’s the entire point.