Short answer
For SaaS, a payment must reliably control entitlement: plan, period, customer organization and activation point. A payment attempt is not a subscription, and refunds require a separate rule.
- Separate the account, invoice, payment attempt and entitlement.
- Activate a plan only after a final successful status.
- Make payment links and SBP part of a controlled invoice.
- Reconcile payments, renewals and refunds by identifiers.
1. Invoice and entitlement model
A SaaS customer buys a defined plan, period or usage allowance. The server creates an invoice with a locked price, currency, tax treatment and entitlement recipient. A payment attempt references the invoice but does not replace it.
Entitlement is stored separately: organization, users, plan, start and end dates. This allows a failed payment to be retried without duplicating a subscription and provides a clear accounting explanation.
- lock the plan and period in the invoice;
- never rely on a price supplied only by the interface;
- connect the payment to the customer organization;
- retain the entitlement change history.
2. SBP and payment links
A dynamic QR or payment link can represent a specific customer invoice. The purpose and interface should show the plan, period and invoice number. Payment validity should align with the commercial offer.
The method is chosen from the options actually available to the merchant. Automatic recurring charging must not be assumed: it depends on the method, approvals and technical implementation.
- create a separate link for every invoice;
- do not reuse a completed payment;
- show which account will be activated;
- provide a safe retry path.
3. Activation and repeated events
Access is enabled only after a confirmed final status. The webhook handler validates authenticity, amount, currency, identifier and current invoice state. A duplicate notification should receive a successful technical response without extending access twice.
If the event is delayed, the interface can show a pending state and refresh status. Support needs invoice and payment lookup, while manual activation should be controlled and logged.
- make activation idempotent;
- validate the amount and invoice ownership;
- do not rely only on a customer redirect;
- log manual decisions.
4. Renewals, refunds and reconciliation
A renewal is a new invoice and payment attempt linked to the same customer. This makes periods auditable and avoids ambiguity. Refunds and access termination should follow the public terms and actual service delivery.
WHITECAPITAL can support approved payment acceptance using SBP, QR, links and APIs. Specific feature availability, including card or recurring scenarios, is determined after KYB/KYC, compliance and banking review.
- keep different billing periods separate;
- reconcile invoices, statuses and settlements;
- describe service termination terms;
- test billing-period boundaries.
Questions and answers
Can one payment link be used for all customers?
For reliable accounting, create a link for a specific invoice, customer and amount.
Are automatic subscriptions supported?
That depends on the available approved payment method and cannot be treated as universal.
When should access be activated?
Only after a final successful server-side status handled idempotently.
Sources and policies
We use official payment-system information and WHITECAPITAL policies. Contractual documents prevail for an individual merchant setup.
This material is for operational orientation and is not a promise of approval, universal method availability, a fixed fee or settlement timing.