Redsys Integrations

What Redsys is and why the virtual POS is contracted through your bank

Redsys is the payment processing company owned by Spain's main financial institutions, and its virtual POS is the most common way to accept card payments in an online store in Spain. But the contract is not signed with Redsys, it is signed with the bank: the bank is the acquirer, sets the terms, approves the payment methods and credits the payments to your account.

The bank provides the merchant details: a merchant code, a terminal number and a secret key the store uses to sign every transaction. With those details we first configure Redsys's test environment and, once everything has been validated, the production one. If your company works with several banks, each one has its own virtual POS and its own key, and the store can use one or the other depending on the brand or the legal entity issuing the invoice.

In terms of data ownership, the store owns the order, Redsys returns the result and the authorisation code of each transaction, and the bank and the ERP own the accounting record of the payment.

How we integrate the Redsys virtual POS

Redsys offers several modes. With redirection, the buyer goes to the Redsys payment page, branded with the bank's identity, and returns to the store when done; it is the simplest option and the one that leaves the least PCI compliance burden on the store. In the embedded mode (inSite), the card form appears within checkout, giving a more seamless experience. There is also a direct server-to-server connection, useful for operations such as charges using a stored reference or refunds.

Whatever the mode, the rule is the same: the buyer landing back on the order-complete page does not confirm the payment. The valid confirmation is the online notification Redsys sends to the store's server, signed with the merchant key. We verify that signature before marking the order as paid, and only then send it to the ERP.

Redsys maintains modules for the most widely used platforms, and we use them as a starting point on PrestaShop and Adobe Commerce (Magento) when they fit. When there are several banks, rules per legal entity or payments inside B2B portals, we build the integration directly on its interface.

Bizum and recurring charges with the Redsys virtual POS

Bizum is not contracted separately: it is enabled on the virtual POS at the merchant's request and approved by the bank. Once active, it appears as an option on the Redsys payment page; the buyer enters their phone number and confirms the transaction in their banking app. For the store, a Bizum payment arrives through the same notification as a card payment, but it should be flagged on the order so refunds and reconciliation handle it correctly.

For customer-not-present charges (instalments, replenishment agreed with trade customers or charges for orders finalised later), Redsys lets you store a card reference on the first payment, with the cardholder's consent. The store keeps only that reference, never the card number, and reuses it for subsequent charges.

Under Strong Customer Authentication (SCA), that first payment must be authenticated with 3D Secure and the following ones are flagged as merchant-initiated. Which exemptions apply is decided by the merchant's bank and the card issuer, so we settle this with the bank before switching on recurring charges.

Refunds and reconciling Redsys with the ERP

Refunds can be made from the virtual POS administration portal, but in an operation with volume it is better to trigger them from the store or the ERP: the credit note is created in the management system, the refund is sent to Redsys over the server-to-server connection and the result is recorded on the order. That way there are no refunds made by hand in the portal that nobody reflects in the accounts.

Reconciliation has a particularity: the money is not settled by Redsys but by your bank, which credits the payments to the merchant account under the agreed terms. That is why reconciliation is done against the bank statement, usually in the Norma 43 format used by Spanish banks, and against the virtual POS transaction detail. One point to resolve at the start is the order number: Redsys requires its own format, so we keep a mapping between the reference sent to Redsys and the order number in the store and the ERP, whether SAP, Microsoft Dynamics 365, Odoo, Holded, a3ERP or Sage.