Where does the buyer pay with Autopay?
The integration uses only the paywall hosted by Autopay. At checkout the buyer sees a single “Autopay” method and, after placing the order, is redirected to the provider’s page to pick a channel there: BLIK, a payment card or a pay-by-link transfer from their own bank. Which channels actually appear depends on your agreement with Autopay, not on the shop configuration.
It is worth knowing what this model implies before choosing the gateway:
- the shop does not process card data or BLIK codes,
- there is no BLIK code field or card form embedded in the checkout - payment always completes on the provider’s side,
- amount limits for individual channels are set by Autopay, which is worth checking in the agreement if you handle large wholesale baskets.
The Autopay module, like the other online payment gateways, is a paid module. Bank transfer, cash on pickup and the credit limit are part of the platform’s open-source core.
How the platform knows an order has been paid
The buyer coming back to the shop settles nothing. Autopay sends them to the same address whatever the outcome, so the return page reads the payment state stored on the order and shows a confirmation, a failure notice, or a waiting message if the notification has not arrived yet.
Status is decided by the messages Autopay sends directly to the shop’s server:
| Autopay message | What the platform does |
|---|---|
| ITN (payment status change) | Verifies the signature (hash), settles the payment and moves the order to the status mapped to success or failure |
| ISTN (settlement transaction, including refunds) | Marks the payment as fully or partially refunded and, on a full refund, puts the order on hold |
The order statuses for a pending, successful and failed payment are set on the payment method, just as they are for PayU or tpay. After a failed attempt, staff can retry the payment for the same order without it being placed again.
Refunds: from the platform and from the Autopay panel
A refund can be issued in two ways, and each has its own precondition on the provider’s side.
- From the platform. Settling a return in the returns module sends Autopay a refund request for the specific transaction, in the same flow as with PayU and tpay. Autopay accepts the request only if API refunds are enabled for the service and its balance holds sufficient funds. The platform marks the payment as refunded when the request is accepted, while Autopay carries out the transfer itself asynchronously.
- From the Autopay panel. A refund issued in the provider’s panel reaches the shop as an ISTN message. That service is not active by default: you need to ask Autopay to enable it and give them the notification address. Without it, refunds made in the panel will not update orders.
What to prepare before go-live
On the Autopay side:
- an agreement and a registered service, for which Autopay issues a Service ID and a shared key,
- a separate set of credentials for the test and the production environment,
- a registered ITN notification address, a return address for the shop and, optionally, an ISTN address,
- API refunds enabled, if they are to be issued from the platform.
Notification addresses must be public and reachable over HTTPS with a valid certificate, so ITN cannot be tested against a local address without a tunnel. The messages are described in detail in the Autopay documentation.
On the Endora Commerce side, the administrator uses the Autopay settings to:
- choose the mode (sandbox or production) and enter the Service ID and shared key for each; the key is stored encrypted and cannot be read back from the admin panel,
- copy the ready-made ITN and ISTN addresses to pass on to Autopay,
- enable the payment method and optionally set a minimum order amount and a list of allowed countries.
Like any payment method, Autopay can be assigned to selected sales channels and restricted to specific buyer organisations.
When to pick Autopay and when another method
Autopay makes sense when the company already has an agreement with it, buyers mostly pay in Poland, and a redirect to the provider’s page is acceptable. For sales aimed at customers abroad, Stripe will be a closer fit.
In B2B an online gateway is rarely the only method. Regular customers usually need no more than an ordinary bank transfer or a credit limit, both of which the platform handles without an external provider, while Autopay covers new customers, prepaid orders and retail sales in a B2C channel. All gateways and the remaining modules are listed on the integrations page.
