Key topics
Related public pages
If you need the product, API or operations page rather than only the article, start with these VPOS.am sections.
Billing schedule is not payment status
Schedule says when payment should be attempted, but it does not prove that money was received.
In CRM, recurring invoice often looks like a repeated task: every month issue invoice, send link and close payment. But billing schedule should not change financial status by itself. It only creates expected payment or payment attempt.
Payment fact should appear after provider webhook or server-side status lookup. If provider supports tokenized recurring, it is a separate contractual and technical scenario. If not, recurring invoices and payment links are a safer starting point.
- store plan, period, due date and amount separately from payment status;
- create payment attempt idempotently;
- do not promise auto-charge without provider support;
- separate invoice generated, payment pending and payment verified.
Retries and dunning should be limited
Repeated attempts and reminders are useful, but they should not spam customer or create duplicates.
Failed subscription payment does not always mean customer refusal. It can be technical error, expired link, temporary bank issue, insufficient funds or plan change. Retries need limit, backoff and clear final status.
Dunning flow should account for notification channels, customer language, grace period and operator intervention. CRM should show next retry, last failure reason and service block date if the business applies it.
- limit retry attempts;
- do not send several active payment links for one period;
- log failure reason without unnecessary card details;
- move period to manual review after limit.
Reconciliation should include plan changes, refunds and partial periods
Subscriptions fail on tariff changes, pauses, refunds and partial periods when there is no audit trail.
Recurring billing should be reconciled beyond successful payments. Plan changes, trial periods, pauses, partial refund, manual extension and payment date shift matter. Without audit trail, support cannot explain why service is active or blocked.
Practical reconciliation shows period status, paid amount, expected amount, provider references, CRM entitlement and exception list. Accounting and support can close month without manual spreadsheet reconstruction.
- compare expected amount and verified amount;
- account for plan change inside period;
- show refund and partial refund as separate events;
- sync service entitlement only after verified payment.
FAQ
Can subscriptions auto-charge cards?
Only if the selected payment provider and contract support tokenized recurring or similar mechanism. Otherwise start with recurring invoices and payment links with reminders.
What should happen after failed recurring payment?
Create failed attempt, store safe failure reason, run limited retry/dunning flow and do not block service without clear grace period or business rule.
When should service access be renewed?
After verified payment or explicit manual override with audit trail. Planned invoice date alone should not renew financially dependent access.
