Payment gateway integration for websites in Azerbaijan

What the integration includes

A working online payment consists of several pieces that have to agree with each other:

• Checkout flow. The order is created on your side first, with a fixed amount and currency, and only then is the customer sent to pay. This prevents the classic error where the amount is changed in the browser.
• Redirect or embedded form. Depending on the provider, the customer either goes to a hosted payment page and comes back, or fills in a secure form embedded in your checkout.
• Server-to-server notification. The provider tells your server that a payment succeeded or failed. This — not the customer returning to the "thank you" page — is what marks the order as paid. Customers close tabs, and networks drop.
• Order statuses. Pending, paid, failed, refunded, partially refunded. Each status triggers the right emails, stock changes and notifications to managers.
• Refunds and cancellations from your admin panel, so staff do not need to log into the provider's dashboard for routine operations.
• Reconciliation. A report that matches orders in your system with transactions on the provider's side, so accounting can close the month without manual comparison.

How the choice of provider affects the work

Businesses in Azerbaijan usually choose between two routes. The first is e-commerce acquiring directly from a bank: the bank provides the merchant account and its own payment page. The second is a payment service provider that puts several payment methods behind one interface; Epoint is one example of a provider operating in Azerbaijan.

From the development side, the differences are practical:

We do not recommend a provider without knowing your turnover, the payment methods your customers use and where your business account is. We assess the technical side — quality of the API, test environment, reliability of notifications — and you compare the commercial terms. For the full picture, see our guide on accepting online payments in Azerbaijan.

Selling to customers abroad

Local acquiring accepts cards issued abroad as long as the bank supports them, but settlement is in manats, and some international customers expect other methods. Companies that sell mainly abroad sometimes use a foreign entity with an international provider. That is a legal and tax decision, not a technical one. We can integrate either route and describe the trade-offs in Stripe and PayPal in Azerbaijan.

How the work goes

1. Provider and scenario. We agree on what is being paid for (a one-off order, a deposit, a booking, a subscription), which currencies are needed and what happens on failure.
2. Test account. You start onboarding with the provider; in parallel we connect its test environment.
3. Checkout and statuses. We build the order logic, the payment step and the notification handler.
4. Refunds and reports. Admin actions for refunds, a reconciliation export and notifications for managers.
5. Testing. Successful payment, declined card, abandoned payment, duplicate notification, refund — each scenario is checked before switching to live keys.
6. Go-live. Live credentials are installed on the server, and the first real transactions are monitored.

What we need from you

• A signed agreement with a bank or payment provider, or at least the start of their onboarding.
• Access to the provider's merchant dashboard and technical documentation.
• Your rules for refunds, cancellations and partial payments.
• Who in your team receives payment notifications and handles disputes.

Security

Card numbers should never be stored, or even received, by your server. With a hosted page or a provider's secure form, the sensitive part stays with the provider, which keeps your own compliance scope small. We also protect the notification endpoint so that forged "payment succeeded" requests cannot mark orders as paid. More in PCI DSS for online stores.