Subscription billing rules and verification specification

A subscription involves more than charging the same amount repeatedly. Customers may retain earlier terms after a price changes. A failed payment does not necessarily terminate either the contract or access. Separate the price list, individual contract, invoice, payment attempt and entitlement so that a change has a defined target. Record both the currently applicable contract version and any scheduled replacement.

The worked example is fictional B2B monthly policy v1. Basic costs KRW 120,000 per month and Pro KRW 180,000; the arithmetic excludes tax. A billing period runs from 00:00 on the first day of a month to 00:00 on the first day of the next month in Asia/Seoul. The end is exclusive. An upgrade takes effect at midnight on its scheduled date only when the additional payment has been confirmed beforehand. A downgrade takes effect next billing period, with no current-period difference adjustment under this example policy.

These amounts and conditions belong to the example business policy. The responsible teams determine actual taxes, documentation, refund and commitment terms. Implementation also requires checking the contracted payment method and its specification. The Toss Payments billing integration guide describes billing contracts and merchant-side scheduling. Registering a payment method or obtaining a billing key does not by itself define the service's plans and cancellation policy.

A plan change has a request time, calculation time, scheduled effective time and payment-confirmation time. Collapsing these into one date can grant access before payment is confirmed. Give the change request an identifier and calculation version, then fix the amount, period and application conditions together. Decide separately how to handle changes against an already-unpaid billing period.

September 2026 has thirty days in the fictional example. An upgrade from Basic to Pro effective at 00:00 on September 16 has fifteen days remaining until October 1. The additional charge is the KRW 60,000 monthly difference multiplied by 15/30: KRW 30,000. Record these inputs under UP-0916. Switch to Pro at the scheduled time only if the additional payment was confirmed beforehand. Otherwise hold the change and retain the existing terms.

This policy divides by the actual number of days in the month and discards fractions of a won once, at the final calculation. Missing prices or dates produce a calculation hold; dates outside the period are invalid. If confirmation misses the scheduled time, agree on a new effective date and amount. Investigate any late-approved payment before another charge is created. Stripe's proration documentation treats unpaid invoices and adjustments separately. The example formula is not a universal gateway rule or a replacement for product configuration.

Renewal and failure processing affect different objects. A contract can remain active while its invoice is unpaid, a payment attempt has failed and access continues during a grace period. Storing everything as one “subscription status” obscures what is owed and which operation can be retried. For each object, define its current state and the confirmed events allowed to change it.

In the worked example, contract S-01 receives October invoice INV-1001. If the first payment attempt fails on October 1, the invoice is unpaid, the contract remains active and access is in grace. Confirmation of the October 2 retry settles that same invoice and restores normal access. Receiving the successful event twice must not apply the invoice or entitlement twice. A delayed success event belonging to September is not evidence that October has been paid.

Use distinct contract, period, invoice, attempt and external-transaction identifiers. Match the target invoice, amount and currency before applying a success event. Track event receipt separately from completion of its business effects. Consult the Toss Payments webhook guide for the integration's event and delivery behavior. The payment integration checklist covers general preparation for authentication, duplicates and conflicting states.

No approval response is different from a confirmed failed payment. A payment may have succeeded while its response was lost. Query the original transaction before creating another attempt. An expired payment method may need replacement rather than repeated charging. Retry confirmed temporary failures only within the conditions permitted by the contract and payment method. Map verified provider error meanings to the service's next actions.

The fictional renewal policy allows retry opportunities at 09:00 on October 2 and October 4 after a confirmed temporary failure on October 1. Verify that the same invoice is still unpaid before each attempt. If it remains unpaid at 00:00 on October 5, an operations check precedes restricting access; the contract remains active. These retry times and the grace period are choices in the fictional policy. They do not describe a shared gateway retry limit or a statement of customer rights.

Do not send unknown approval states or conflicting records straight into that schedule. Route them for inquiry and operations review, holding duplicate charges and incorrect restrictions. Customer messages should distinguish confirmed nonpayment, processing under investigation and a payment method requiring replacement. Use channels and consent arrangements that the service actually supports. Assign the final state check through the inquiry, diagnosis, approval and execution roles in payment operations.

End-of-period cancellation defines when current access ends and stops the next period's charge. Mid-period termination may also require a decision about the effective date and money to adjust. A request, internal review, amount approval, provider processing and reconciliation are separate states. Do not display a completed refund merely because a request was accepted, and do not repeat a cancellation whose result is unknown.

The separately approved adjustment example ends Pro access at 00:00 on September 21. Under the fictional contract, the responsible owner approves ten unused days at KRW 180,000 × 10/30: a KRW 60,000 adjustment. The earlier Basic charge of KRW 120,000 and upgrade charge of KRW 30,000 total KRW 150,000. After the adjustment completes, the remaining paid amount is KRW 90,000, and no next-period invoice is generated. ADJ-0921 links the effective time to the approval evidence.

KRW 60,000 is the amount approved in this fictional agreement, not a statutory refund amount. Actual execution must check the refundable balance and processing rules of each original transaction and allocate the adjustment accordingly. Verify that invoice adjustments match actual cancellations or payouts. Link the original transaction, adjustment, cancellation event and settlement effect to the reconciliation rules and operations workbook so finance and operations trace the same money.

The verification sheet connects an approved rule identifier, test input, expected amount and state, execution result and evidence. UP-0916 with advance payment confirmation expects KRW 30,000 and activation on the scheduled date; unconfirmed payment expects a held change. A duplicate renewal-success event should settle one invoice once. Success from an earlier period must not clear current nonpayment. Scheduled cancellation must prevent the next invoice from being created.

Test date boundaries, different month lengths, missing amounts, a zero price difference and dates outside the permitted period. Arithmetic checked locally does not prove a real payment or refund succeeded. An integrated test environment must exercise queries, redelivery, approval conflicts and cancellation results. Production readiness separately requires the contracted payment method, keys, scheduler, customer notices and inquiry/refund permissions. Leave unexecuted cases marked as such, with an owner and planned check.

IXC's recurring billing service implements the connections between plans, contracts, invoices, retries and cancellation. Together with payment integration, it defines the data model and integration scope for the approved policy. Include current terms, change examples and unresolved nonpayment or cancellation questions in an inquiry to define development, verification and operations handover responsibilities. Shared specifications contain no secret keys or real customer payment details.