Payment acceptance for e-commerce: launch model

1. From cart to payment

Before creating a payment, the store validates inventory, total price, delivery, discounts and currency. The order receives a stable identifier and the server sends the amount to the payment infrastructure. The payment purpose should clearly match the purchase.

Checkout should display the total, seller, support contacts and material terms. The choice between SBP, cards and payment links depends on the audience and approved methods. Card acquiring is available only where supported and agreed.

• do not trust an amount supplied only by the browser;
• record the applied price and discount version;
• limit payment-session validity;
• do not present an unavailable method.

2. QR, link and customer return

For SBP, a dynamic QR or link is generated for a specific order. The customer may return to the store after using a banking application, but browser return does not confirm payment. The server-side status is authoritative.

The result page should handle delays: display a pending state, poll safely and avoid creating another order without an explicit action. If the customer closes the tab, a webhook can still update the order.

• do not use a generic QR for an automated cart;
• separate the return URL from payment confirmation;
• show the customer the order number;
• provide safe status rechecking.

3. Order, inventory and fulfilment

Inventory reservation and fulfilment timing depend on the business process, but shipping should not start from a created-payment status. A successful event is recorded idempotently so a duplicate webhook cannot decrement stock or grant benefits twice.

After failure or expiry, the order may remain available for another payment under store rules. The new attempt needs its own identifier while retaining the link to the order.

• define the final paid status;
• protect handlers from duplicate execution;
• log every order-state change;
• separate orders from payment attempts.

4. Refunds, reconciliation and launch

A refund references the successful payment attempt and is accounted for separately. Daily reconciliation compares orders, statuses, fees and registers. Before launch, test double clicks, delayed webhooks, partial refunds and external-service unavailability.

WHITECAPITAL supports approved setups using SBP, dynamic QR, payment links, APIs and operational statuses. Card availability, pricing and other terms are determined after business review.

• publish a current refund policy;
• run a test reconciliation;
• prepare support instructions;
• monitor errors and incomplete payments.

Questions and answers