Payment API for websites, SBP and QR

What the payment API does

A payment API links an order in the merchant’s system to a payment flow. The server creates a payment, stores its identifier and sends the customer to a hosted page or presents a payment link or QR code. The result is delivered through a server channel as well as the browser journey.

The integration may support SBP/C2B, dynamic NSPK QR, payment links and other agreed payment methods. A card flow is available only where suitable banking infrastructure exists and separate approval has been granted.

• create a payment with amount, currency and reference;
• receive a payment link or QR data;
• query the current payment status;
• receive webhook or callback notifications;
• use transaction registers for operational reconciliation.

A correct payment lifecycle

An order and a payment are different records. One order may have a failed attempt followed by a new payment, so the merchant should retain both identifiers and enforce valid status transitions. Goods or services should be released only after a confirmed final server-side status.

A customer may close the tab, return to the website before the notification arrives or reopen a link. A success page is useful for the customer but should not be the only evidence that funds were received.

• create an order in the merchant system;
• create a linked payment;
• show the approved payment method to the customer;
• receive and verify the server notification;
• update the order once and include the transaction in reconciliation.

Webhooks, retries and security

The webhook handler should use a secure connection, validate notification authenticity according to the documentation, respond quickly and move heavy work to a queue. Repeated delivery of the same event must not release goods or change a balance twice.

Integration secrets must not be placed in frontend code, public repositories or logs. Access should be separated between test and production environments, reviewed periodically and rotated if compromise is suspected.

• server-side key and secret storage;
• notification validation under the documentation;
• idempotent handling of retries;
• logging without payment secrets;
• reconciliation of API statuses with registers.

How to receive documentation and access

The company first applies and completes KYB/KYC, website, business-model, product and compliance review. After the contract, payment methods and banking setup are agreed, the merchant receives the applicable technical materials and environment parameters.

Before production, the teams test positive and negative cases, expiry, duplicate notification delivery, cancellation, refund where available and reporting. Fees, limits and settlement timing are agreed individually.

Frequently asked questions