Services moving from manual invoices to subscriptions
Existing contract terms are translated into plan rules, and the final billing period on the old system is fixed before the cut-over.
Recurring Billing
A billing build service that implements subscription billing end to end, from plans and invoicing through failed-charge retries to cancellation.
- Payments
- Integration
- Operations
- Risk response
01Overview
Service overview
Recurring Billing implements the subscription billing lifecycle in code, from plans and invoicing through failed-charge retries to cancellation. Plan-change and proration rules are settled at kickoff. Once those rules stand, there is no month-end ritual of fixing exceptions by hand.
02Who it fits
Where it fits
Products with complex plan changes and proration
How each upgrade and downgrade is calculated is settled case by case and written down.
Teams that need to reduce churn from failed payments
Retry intervals and customer messages are split by failure reason, so one temporary decline does not end a subscription.
03What we deliver
Scope of delivery
01
Plan and subscription lifecycle
Plans, add-ons, activation, change, suspension, and cancellation are defined as one explicit state model. When sales proposes new terms, they are configured as a plan rather than written as code.
02
Invoices, tax, and proration
Usage and period are calculated into an invoice, down to the conditions for issuing a tax document. A customer who switched plans mid-cycle is charged by the rule, not by hand.
03
Retries, dunning, and cancellation
Failed charges are retried by reason, with the notice schedule and the point of service restriction set out. Charges to recover and accounts to close never run down the same path.
How the service works
From subscription terms to billing and retries
Separate plan and contract terms, then implement billing and reason-based retries across the subscription lifecycle.
Define plans and subscription states
Bill by period and usage
Handle failed payments and cancellation
04Why this way
Points of difference
Each point lists the deliverable that backs it.
Old plan terms stay pinned to the contract
Pricing always changes, and every change leaves a cohort on the old terms. Plan, contract, and billing target are kept separate, so previous terms stay pinned to the contract while new ones apply from the next sign-up. Promotions and negotiated discounts are contract attributes as well, not exception branches in code.
Backed by
- Transaction state map and RACI
- Integration spec and exception design
Client work · Artist platform
Artist platform, company A — point top-up and management
Top-up, spending, and balance were settled into one state model and attached to the running service.
Learn moreRetry timing is not left to the provider defaults
Failed charges include temporary ones, such as insufficient funds or an expired card. In Korea a recurring charge is re-initiated on the merchant side, against a billing key the payment provider issues. IXC is a Toss Payments partner and works with the billing-key integration Korean gateways use. That is why the retry interval and the count per reason code are set in the build instead of left at the provider default. Service restriction applies only after the recovery attempts are exhausted.
Backed by
- Reconciliation rules and runbook
- Settlement report template and anomaly rules
Client work · AI character chat
AI character chat, company M — payment integration
Authorization, cancellation, and refund states were fixed first, and the provider was connected on top of them.
Learn more05How to start
From first call to kickoff
Every stage ends with an agreed scope and a deliverable in your hands.
Step 01
Map the transaction
We write out every transaction state and its owning team from authorization through cancellation, refund, and settlement in one state map.
DeliverableTransaction state map and RACI
Step 02
Integrate safely
We build the APIs, security, and data flows assuming failure, retry, and duplicate authorization, then verify them in the sandbox.
DeliverableIntegration spec and exception design
Step 03
Operate and reconcile
We join monitoring, exception handling, and reconciliation into one loop and classify the cause of any anomaly on the day it occurs.
DeliverableReconciliation rules and runbook
Step 04
Stabilize settlement
We hold the closing cycle and fix the report format and anomaly rules so every difference can be explained at T+1.
DeliverableSettlement report template and anomaly rules
06Contract options
Ways to work together
- Remote delivery
- Fixed price
07Service levels
Service levels
Same day
Suspicious transactions traced to cause
T+1
Settlement reconciliation report
3routes
Domestic PG, wallets, and overseas payments
Fuel delivery platform, company N — billing in progress
A delivery platform that could not run properly when we took it over, held back by frequent errors and bugs. Weekly releases brought it back, and it now handles 500 to 600 million won of transactions a month.
What we doRecurring charges are being moved onto card auto-billing. Plans, retry-on-failure, and customer notices are settled before the integration goes in.
What it leavesBecause billing is going on top of a platform already moving money, the first condition is that no order is left in an unknown payment state.
Artist platform, company A — point top-up and management
The platform needed a way to top up and manage the points used in artwork transactions.
What we doTop-up, spending, and balance were settled into one state model and attached to the running service.
What it leavesTransactions that move on points rather than a payment method sit in the same record.
AI character chat, company M — payment integration
A service built with generative tooling had to take payments for the first time.
What we doAuthorization, cancellation, and refund states were fixed first, and the provider was connected on top of them.
What it leavesIt went into operations with no transaction left in an unknown payment state.
09FAQ
Frequently asked questions
No. The cut-over date and the final billing period on the old system are fixed first. The first cycle after migration is prorated. Customers who must keep their existing terms have those terms pinned to the contract.
Yes. We usually design the integration and operating procedures around the contracts already in place, and when fee or settlement-cycle terms change, only the reconciliation rules need to be re-aligned.
By default we store no card data and use provider tokens instead. Data retention scope and access rights are defined at design time, and processing records and access logs are kept as the evidence each standard requires.
You can run it in-house, jointly, or hand it to us. In every case you receive the reconciliation rules, the incident runbook, and the provider escalation contacts, so the procedure survives a change of owner.
We configure reports and detection rules to explain differences at T+1. Transaction states for authorization, cancellation, refunds, and settlement are aligned with reconciliation rules so the origin of a difference can be traced.
Read access comes first. Transaction views, logs, and provider administration are opened only to the scope needed for intake and diagnosis. Refund execution and rule-change permissions are assigned after approval procedures are defined.
We share the findings from the first stage, then agree scope and schedule on that basis before delivery. A finished request for proposal is not required: the current environment and the outcome you want are enough to start.
Engineering & Operations
2026-09-26 · 15 min read
Does connecting a recurring-payment API complete a subscription service?
Subscription billing design connects payment methods, contracts, charges, payment attempts, and entitlements through change, failure, and cancellation policies. A successful first payment still leaves responsibility for next month’s failure, cancellation during retries, plan changes, and access revocation.
Reliability & Observability
2026-09-26 · 20 min read
Payment succeeded, but the order is missing: designing payment and order consistency
Payment/order consistency separates payment facts from order and fulfillment records, then recovers only missing steps using verified evidence. External approval and a local database write may not complete together. Treating an unknown outcome as failure can cause duplicate payments or issuance.
Reliability & Observability
2026-09-26 · 17 min read
Why partial-cancellation amounts drift: separating discounts, shipping, and refunds
Calculate a partial cancellation as the difference between the confirmed current balance and the amount that should remain after cancellation, then reconcile discounts, shipping, and successful cancellations. Equal product prices do not imply equal individual refunds when remaining-item discounts and shipping conditions change.
12Related resources
Resources for this service
Guides and checklists you can use during review and kickoff.
See all resources
Guides
2026.09.10
Subscription billing rules and verification specification
A worked fictional B2B subscription policy for documenting plan changes, failed billing and cancellation as contract rules and expected results.
Contact
Contact us
Tell us your current environment and target outcome, and our team will review it and reply.
Direct line
Phone lines are open weekdays 09:00–18:00
ServiceRecurring Billing
Collection and use of personal information
- Purpose · Responding to and following up on this inquiry
- Items · Name, company, work email, message, visit source (first page visited, referring site domain, campaign parameters)
- Retention · 36 months from the date consent is given
You may decline; the inquiry cannot be submitted without consent.
More ways to explore