+994512060920
The site is ready, the products are uploaded, and the design looks good. But once a customer adds an item to the cart, one question remains: how will you get paid? Some businesses are still stuck on "place the order, pay the courier in cash." It works, but without online payment part of your orders get abandoned halfway, because customers want to pay by card right away.
Setting up an online payment system is simpler than it looks, but a few mistakes along the way can be expensive. In this article we'll explain, in simple terms, how the process works, what options exist in Azerbaijan, and the technical and security points to watch.
How Does Online Payment Work?
When the user presses "Pay," they enter their card details not on your site but on the secure page of the bank or payment provider. This is the most important principle of the whole process. A simple flow looks like this:
- The customer confirms the cart, the system creates an order and sets its status to "payment pending."
- The site sends a request to the payment provider: the amount, the order number and a return address.
- The customer is redirected to the payment page and enters their card details there.
- If needed, 3D Secure confirmation is performed (the bank asks for approval by SMS or in its app).
- The payment provider reports the result to your system.
- The system updates the order status: successful, failed or cancelled.
- The customer is returned to the site's result page.
This way the card number never passes through your server. That is a big advantage both for security and for liability.
What Options Exist in Azerbaijan?
There are two main directions for accepting card payments on a website.
1. A bank's internet acquiring service
Some banks offer merchants a service for accepting card payments directly. For example, PASHA Bank's "Elektron ticarət" (e-commerce) service lets you accept card payments on a website or in a mobile app without a POS terminal. The bank's page states that the service supports Visa, Visa Electron, MasterCard and Maestro cards, offers 3D Secure as a security service, and includes recurring payments, secure storage of card data, and full or partial refunds.
The advantage of the bank route is a direct contract with the bank and funds going straight to your account. The downside is that each bank may require its own contract and its own technical integration.
2. A payment aggregator
An aggregator is a service that brings several payment methods together behind a single API. For example, Epoint presents itself as a digital payment aggregator for small and medium businesses, and its site states that it is licensed by the Central Bank of Azerbaijan. According to the site, it supports Visa, Visa Electron, Mastercard and Maestro cards, Apple Pay and Google Pay payments, recurring payments, installment payments, and QR code and invoice payments. For integration it offers an API and ready-made scripts for platforms like WooCommerce and OpenCart.
The advantage of an aggregator is a fast start, especially for a small business. When choosing, though, you must compare the commission, the time it takes for funds to reach your account, and the support terms.
| Criteria | Bank acquiring | Payment aggregator |
|---|---|---|
| Contract | Directly with the bank | With the aggregator |
| Speed of getting started | Depends on paperwork and approval | Usually faster |
| Payment methods | Cards and services the bank supports | Several methods in one place |
| Integration | Follows the bank's technical documentation | A single API and ready-made modules |
| Best suited for | Larger, established businesses | Small and mid-sized businesses, startups |
Commission rates, terms and supported methods can change. So before deciding, check the provider's official terms or ask its sales team in writing. Don't rely on figures from third-party articles.
The Technical Side of Integration
Technically, a payment integration is usually an API integration. The main stages are as follows.
Creating the order
An order must exist in your system before the payment. Every order needs a unique number and an expected amount. When the payment result arrives, the system finds the order by that number and updates it.
Callback or webhook
The payment result arrives in two ways: when the customer returns to your site, and through a separate notification the payment provider sends to your server (a callback or webhook). The most important rule: the decision to mark an order as paid must rest on a verified notification arriving at the server, not on the customer's browser. A user can close the return page, lose their connection, or edit the address by hand.
Signature verification
Payment providers usually sign the notification with a secret key. Your server must verify this signature. Without verification, someone could send a fake "payment successful" request and get a free order. This is one of the most common security holes. You can also read our API security article on this topic.
Checking the amount
The amount in the notification must match the amount on the order. You must never take the amount from the request the customer sends. It should always be read from the order stored on the server.
Duplicate notifications
A payment provider may send the same notification more than once. Your system must handle this properly: if the order is already marked as paid, a second notification must not process the order again (idempotency).
What Is 3D Secure and Why Does It Matter?
3D Secure is a security layer that requires the cardholder to confirm the payment with an extra step, such as a one-time code from the bank. It reduces the risk of a card being used by someone else. You usually don't need to build it yourself, since the payment provider handles it on its own page. Your job is to handle the failed-confirmation case properly.
PCI DSS and Card Data
PCI DSS is a security standard for organizations that process card data. The simplest rule is this: never store the card number, CVV code or expiry date on your own server or in your database. If card data is entered only on the payment provider's page, the burden on you drops considerably. Card data also must not end up in your logs, something we noted in our monitoring and logging article.
In addition, every page of the site should run over HTTPS.
Order Statuses
For a payment system to work properly, order statuses need to be clear:
- Pending: the order has been created, but payment hasn't been completed yet.
- Paid: a verified notification has arrived and the amount matches.
- Failed: the payment was declined or 3D Secure wasn't completed.
- Cancelled: the customer left the payment page and the time ran out.
- Refunded: fully or partially refunded.
You also need a mechanism that automatically checks or cancels orders that stay in the pending status for too long. Otherwise stock can remain blocked for nothing.
Refunds and Accounting
Accepting payment is only half the job. You also need to plan for money returning when a customer sends a product back, for reconciling payments with your accounting records, and for reports. You have to check that every payment matches across your system, the payment provider and the bank account. If this isn't automated, month-end accounting eats up a lot of manual time. We also touched on accounting and ERP integration in our B2B e-commerce article.
Testing: Before Production
It isn't right to test a payment system directly with real money. Payment providers usually offer a separate test system. In Staging, you need to check these scenarios:
- A successful payment
- A declined payment
- 3D Secure confirmation not completed
- The user closing the payment page
- The same notification arriving twice
- A fake notification or one with a wrong signature
- Partial and full refunds
- A notification arriving late
After moving to Production, keep watching the payment success rate. A sudden rise in failed payments is often the first sign of a technical problem. Proactive monitoring is useful here.
The Most Common Mistakes
- Confirming payment based on the browser: Marking an order as paid from a parameter on the return page opens the door to fake payments.
- Not verifying the signature: You need to confirm that the callback really comes from the payment provider.
- Taking the amount from the customer: The price must always be calculated on the server.
- Ignoring duplicate notifications: The same order gets processed twice, and stock or bonuses are miscalculated.
- Not cleaning up pending orders: Stock gets blocked and reports get messy.
- Going to Production without testing: The most expensive mistakes show up on a real customer's payment.
- Choosing without learning the terms: The commission, settlement time, refund rules and support should be clarified before signing.
- Depending on a single payment route: If the provider has a problem, sales stop. If possible, plan a backup option.
How to Get Started
- Define your business type: sole proprietor or legal entity, size and turnover.
- Compare the official terms of several providers: commission, onboarding requirements, settlement time, supported cards and wallets.
- Design the order and status logic in advance.
- Build the integration in Staging following the provider's technical documentation.
- Test every scenario (successful, failed, duplicate, fake).
- Move to Production and also check payments by hand during the first days.
- Set up monitoring and reporting.
A payment system may look like a simple module, but it is closely tied to order logic, stock, accounting and security. In projects with complex business processes, this part is usually planned as custom software. For other steps to grow your sales, you can look at our article on increasing sales with an e-commerce website.
Frequently Asked Questions
Which route suits a small online store better?
An aggregator often gives a faster start, because it comes with ready-made modules and a single API. As turnover grows, you can also compare a direct contract with a bank. Before deciding, check the terms of both routes from official sources.
Can I store card data on my site?
No, you shouldn't. Card data must be entered on the payment provider's page and must not pass through your server.
What event confirms a payment?
A signature-verified notification that arrives at your server. The customer returning to your site does not, on its own, show that the payment succeeded.
Is it possible to add Apple Pay and Google Pay?
That depends on the provider you choose. Some aggregators support them, but each provider's terms need to be checked separately.
How long does integration take?
A few days with a ready-made module for a simple store, and longer for a system with custom order and accounting logic. The timeline mostly depends on how complex the business process is.
What should the customer see when a payment fails?
A clear message and a chance to try again. Instead of writing "An error occurred," showing the reason (for example, confirmation wasn't completed) and the next step is better for not losing the customer.
Conclusion
An online payment system is not just a "button that accepts cards." A well-built flow creates the order, routes the payment securely, confirms the result with a signature, updates statuses, and supports refunds and accounting. In Azerbaijan there are both bank acquiring services and payment aggregators, and the choice depends on your business size, the terms and your technical needs. The core rules don't change: don't store card data, accept payment only on a confirmation that reaches your server, and test every scenario before going to Production.
If you want to set up online payment integration for your site, or review the system you already have, get in touch with the Crocusoft team. Let's look at your business process together and find the right path.
