Three subscription events that need separate handling
A subscription product has at least three payment moments that are easy to conflate: the first purchase, a renewal and a user-initiated upgrade or downgrade. Each should be verified against your approved bKash, Nagad or Upay integration independently; a successful first payment does not predict that a later renewal attempt succeeded.
Confirm first whether your approved integration supports a merchant-initiated recurring charge at all. Mobile wallet payments are commonly a customer-initiated action completed in the customer's own wallet app, rather than a stored card your system can silently charge again. If your approved route has no supported auto-debit mechanism, "renewal" in practice means prompting the customer for a new payment each billing cycle, not an automatic background charge, and your product and reminder flow should be built around that. Do not design around an automatic-renewal assumption that your integration does not document.
This guide does not assume any specific provider's status names or a guaranteed retry schedule for failed renewals; map your own approved integration's actual renewal and retry behaviour before relying on it.
Checks before activating or renewing access
- Freeze the activation decision for the event in question. Keep the account identifier, plan/SKU, BDT amount, provider payment reference, billing period and timestamps. Restrict access to account and payment data to the systems that need it.
- Retrieve the authoritative payment outcome using your approved integration's server-side query or verified notification process, rather than trusting a client-side success screen.
- Match the payment reference and amount to the specific billing period it covers. A first payment activates the initial period; a renewal payment extends it. Do not extend the same period twice from one payment, and do not activate a new period from a payment that was already applied.
- On a failed or unconfirmed renewal, follow your own grace-period and downgrade policy rather than cutting off or extending access ad hoc. Record the failure reason your integration reports, where available.
- Commit the payment record and the access-period update together where possible, using a unique idempotency key per billing event, so a retried renewal notification cannot grant a second period.
Hypothetical renewal-failure case
A user's monthly BDT 299 subscription is due for renewal, and the app prompts them to complete a new wallet payment for the next period, since the approved route has no merchant-initiated auto-debit. The user confirms in their wallet app, but the app shows the account as active from cached state before the backend has received a verified payment confirmation. These amounts and timings are invented, not channel timing promises.
Keep the account in its current grace state until the renewal payment is verified one way or the other. If the renewal is confirmed, extend the billing period once from that payment. If the renewal fails or is not confirmed within your policy window, apply the agreed downgrade rather than assuming success from the app's cached display.
A launch-test checklist for engineering and support
- A renewal payment is confirmed after the app has already shown a grace-period downgrade notice; the account is restored from the verified payment, not left downgraded.
- Two renewal notifications arrive for the same billing period; only one period extension is recorded.
- A user cancels and resubscribes within the same billing period; the billing history remains traceable and no period is double-charged or double-extended.
- A payment is confirmed but the access-grant update fails to apply; the activation is retried from the stored payment record, not re-charged.
- A downgrade or cancellation request arrives while a renewal payment is still being verified; the two are reconciled according to your policy rather than racing each other.
Frequently asked questions
Can bKash, Nagad or Upay auto-renew a subscription like a stored card?
Not necessarily. Confirm this with your approved integration rather than assuming it. Many mobile wallet payments require the customer to confirm each payment in their own app, so a "renewal" may need a new customer-initiated payment each cycle instead of a silent auto-debit.
Should the app activate access from a success screen alone?
No. Activate or renew only after your server verifies the payment through your approved integration's query or notification process.
Is this the same as duplicate webhook handling?
No. Duplicate handling protects against a repeated event. This workflow also resolves which billing period a verified payment belongs to and how a failed renewal should change access.
Does this confirm PAYJN accepts every content or subscription product?
No. Disclose the real product and any adult, wagering or cash-redeemable features. Business and channel eligibility need separate approval.
Related checks and next step
The billing-period and access-grant controls above are proposed merchant design practices. Confirm your current provider rules and PAYJN-approved methods before testing; no supplier relationship, refund route or settlement time is implied.
Discuss a Bangladesh digital-entertainment payment flow
Share your company/product URL, business model and role, registration jurisdiction, actual payment markets, methods, current or forecast monthly volume, currency, average order size and launch plan. A contact click or prepared enquiry is not a received application.
Discuss a Bangladesh digital-entertainment payment flow