Redsys and Bizum for your store: fees and integration

Redsys does not charge you a fee: your bank does. Learn how the virtual POS is integrated, the limits of Bizum (€0.50–€5,000 on Stripe), and what information is actually public.

Redsys does not charge you a fee: it is the technical infrastructure used by Spanish banks. The price is set by your bank, with a merchant discount rate that nobody publishes. Bizum is contracted through that same virtual POS or via a gateway like Stripe, which does publish its rates: 1.5% + €0.25 per transaction.

Almost all Spanish ecommerce pricing guides talk about platforms, hosting, and design. Almost none mention the line item that takes a percentage of every sale for the next three years. Here, we talk about that.

Redsys is not your payment gateway: it is the road

Let’s start by clearing up the confusion that drags everything else down. Redsys Servicios de Procesamiento is the company that processes card transactions for most Spanish banks. You are not a Redsys customer. Your bank is.

What you contract is a virtual POS with your financial institution. The bank provides three things: a nine-digit merchant code (FUC), a terminal number, and a secret key used to sign every request. The payment screen, the certificate, the protocol, and the response codes belong to Redsys. The price belongs to the bank.

This distinction has a practical consequence that should be understood before requesting quotes: you do not negotiate with Redsys; you negotiate with your local bank branch. And because you negotiate with your branch, the rate they offer depends on your turnover, your history, and whether you have asked for a second offer.

The industry norm: The provider tells you "we integrate Redsys, the fee is 1%" and you sign. 1% is a brochure number: nobody has seen it in writing, and nobody will tell you where it comes from.

Our criteria: You ask your bank for the merchant discount rate in writing, broken down by debit, consumer credit, corporate card, and non-EEA card. These are four different prices, not one.

The only thing that is public: the interchange fee

There is one part of the cost that is public and verifiable, and almost no Spanish article mentions it.

Regulation (EU) 2015/751 sets caps on the interchange fee, which is the portion of the commission that the acquiring bank pays to the cardholder's issuing bank.

Now, an important warning: that is not your fee. The interchange fee is a component of the cost, not the final price. On top of this, the card scheme fee (Visa, Mastercard) and the acquirer's margin are added. The sum is called the merchant discount rate, and it is what is deducted from each settlement.

And these caps have fine print that matters for an online store: they only cover consumer cards issued within the European Economic Area. A corporate card, or a card issued outside the EEA, falls outside the cap. If you sell to the UK, Latin America, or businesses, your real average cost will not look like your neighbor's who sells cosmetics in Valencia.

The interchange caps from Regulation (EU) 2015/751 were verified on EUR-Lex on 08-27-2026 and remain in force. The discount rate your bank applies is neither public nor comparable between entities: ask for it in writing before signing the virtual POS contract.

How Redsys is actually integrated

Redsys offers three paths: redirection, InSite (embedded form), and REST or SOAP connection. It also publishes modules for WooCommerce, PrestaShop, and Magento, and accepts Bizum, Apple Pay, Google Pay, and PayPal through the same terminal.

For the vast majority of stores, redirection is the correct answer. Not because it is more elegant, but because it removes card data from your server, taking a large part of the PCI-DSS scope with it. We choose redirection to reduce the risk surface, not to save hours.

Integration via redirection consists of a POST form with three fields:

And within that JSON, there are four details that cause 90% of integration failures in the first week:

• The amount is without a decimal separator: the last two digits are the cents. A €49.90 order travels as 4990. Multiplying by one hundred incorrectly is the fastest way to charge one hundred times more.
• The currency is the ISO-4217 code: 978 for euros.
• The order number has 4 to 12 alphanumeric characters, and the first four must be numeric. If your store generates identifiers like ORD-2026-001, it will not work.
• The FUC is nine digits and the terminal up to three. A missing leading zero in a spreadsheet will crash the entire environment.

Tests are performed against https://sis-t.redsys.es:25443/sis/realizarPago and production lives at https://sis.redsys.es/sis/realizarPago. These are two different URLs and two different keys: changing the URL and forgetting the key is a classic Friday afternoon mistake.

The notification is the truth, the browser is not

This is the architectural decision that separates an integration that holds up from one that bleeds orders.

The customer returns to your store via a return URL. That return may never happen: they close the tab, lose coverage, or the mobile kills the browser. If your store marks the order as paid upon return, you will lose payments that actually occurred.

We confirm the order with server-to-server notification, not the browser return. The return only displays a screen. The notification, with its validated signature, is what changes the status.

And you must always validate the signature. An unverified notification is a public endpoint that anyone can call to mark orders as paid.

• The order status is changed by the signed notification, never by the return URL
• The HMAC SHA256 signature is validated on every received notification, without exception
• The notification endpoint is idempotent: two notices for the same order do not duplicate the charge or the email
• Code 9915 (cancelled by user) is treated as a recoverable abandonment, not an error
• Code 913 (duplicate order) does not generate a new order
• Code 101 (expired card) returns a message the customer understands, not a number
• Codes 0000 to 0099 (authorized) are distinguished from the rest
• Test and production keys are in environment variables, not the repository
• There is a daily reconciliation between store orders and bank settlements

Bizum: two paths that are not the same product

Bizum in ecommerce can be activated in two ways, and the difference between them is not the price: it is the contract, the limits, and who answers when something fails.

Via Redsys. Bizum travels through your virtual POS as another payment method. Your bank activates it, it settles with the rest, and the commission enters into the same opaque negotiation as cards.

Via Stripe. Stripe publishes its rates and rules. That is a real advantage when you are deciding, even if the list price is worse than what a bank might offer you with volume.

The operational restrictions of Bizum on Stripe, verified in their documentation on 08-27-2026, are what no Spanish guide includes:

Three design consequences that stem from this table:

1. If you sell subscriptions, Bizum does not work as a primary method. It does not support recurring payments. You need a card or SEPA direct debit behind it.
2. If your model charges upon shipping, it doesn't fit either. Without manual capture, you cannot authorize today and charge in three days.
3. If your average ticket exceeds €5,000, the button is unnecessary in that cart. Displaying a method that is going to fail is worse than not displaying it at all.

There is also a list of categories excluded from Bizum on Stripe that surprises many people: jewelry and watch stores, precious metals and stones, art galleries, financial entities, religious organizations, political organizations, cryptocurrencies, gambling, timeshares, and fundraising for charitable and social entities. If you have an NGO and were counting on Bizum for donations via this route, check it before designing the donation page, not after.

Let's compare it with what the same gateway charges for cards in Spain, according to their pricing page consulted on 08-27-2026:

Look at the last row. Twenty euros per received dispute, win or lose. In a store with a low ticket size, a high dispute rate eats up the margin faster than the commission.

Strong Customer Authentication also has numbers

Delegated Regulation (EU) 2018/389 regulates strong customer authentication. Article 16 allows for exemptions from authentication for remote electronic payments of low value when three conditions are met simultaneously: the transaction amount does not exceed €30, the cumulative amount since the last authentication does not exceed €100, and no more than five consecutive transactions are chained without authentication.

Article 18 opens another door, that of transaction risk analysis, provided that the provider's fraud rate remains at or below the benchmarks in the annex: 0.13% for remote electronic card payments and 0.06% for remote transfers.

I translate this into a product decision: you do not choose the checkout friction; regulation and your acquirer's fraud rate do. Designing an authentication step that looks good on mobile is not cosmetic; it is conversion.

What it costs to integrate this and the VAT involved

There is a tax asymmetry here that is worth clarifying before comparing budgets.

Payment service commissions and the fees of those integrating the gateway are not treated the same way regarding VAT. The development of your store is a provision of services subject to the general rate of Article 90 of Law 37/1992. Bank commissions for payment operations move in the field of financial exemptions of Article 20.One.18th of the same law. It is not the same, it is not added in the same way, and you do not decide it: check it with your consultancy with the virtual POS contract in hand.

— = data being measured; we will publish it once we have our own sample.

This is how we approach it:

We work with a fixed price per phase agreed upon before starting, with no surprise hours. We deliver the code, source files, and documentation. And if your case does not fit with what we do, we tell you in the first 30-minute call.

We set the integration price before we start; you set the commission for each sale with your bank, which is why we tell you what to ask for in writing.

A well-integrated gateway goes unnoticed. You notice the one that loses one order out of every hundred, and nobody knows why until the books are reconciled at the end of the month.

The risk of a gateway is not on launch day: it is on month three, when the bank settlements and store orders stop matching and there is no record of notifications to look at.

Bring two things to the first 30-minute call: your virtual POS contract with the discount rate in writing and the format of the order number your store generates today. With that, we will tell you in that half hour where your checkout will bleed. And if we find nothing to fix, we will tell you that too.

Frequently asked questions

Does Redsys charge a commission for each sale?

Redsys processes the transaction, but the commission is applied by your bank through the discount rate agreed upon in the virtual POS contract. Ask for that percentage in writing and broken down by card type: nobody publishes it, and nobody will offer it to you without you asking.

Can I charge monthly subscriptions with Bizum?

Not via Stripe: their documentation expressly indicates that Bizum does not support recurring payments (consulted 08-27-2026). You will need a card or SEPA debit for recurring payments, and you can only use Bizum for the first charge or for one-off purchases.

What is the maximum amount for a purchase with Bizum in an online store?

On Stripe, the maximum per transaction is €5,000 and the minimum is €0.50 (consulted 08-27-2026). Via your bank, the limits are set by your institution: confirm them before designing the cart, because a method that fails at the last step costs more than one that does not appear at all.

Do I need PCI-DSS certification if I integrate Redsys?

If you use the redirection connection, card data does not pass through your server and your PCI-DSS scope is substantially reduced, although it does not disappear. Confirm the questionnaire that corresponds to you with your bank: we cannot certify you ourselves, and we are not going to tell you yes just to close the project.

Is Redsys or Stripe better for a Spanish store?

It depends on your volume and your market: Stripe publishes its rates and unifies cards, Bizum, and SEPA debit into a single integration, while a bank with volume usually improves that price in exchange for opacity and more reconciliation work. If you sell only in Spain and have low turnover, the published rate will give you fewer surprises than a negotiation you cannot compare.

Keep reading

• Setting up an online store in Spain: platform, real 3-year cost, and gateways
• WooCommerce or Shopify in Spain: the crossover point by turnover
• I have traffic and I am not selling: diagnosis in 12 checks
• Do website prices include VAT? How to read a budget as a freelancer or SME
• Total cost of a website at 36 months: the number almost no one gives you

Transparency note. Some of our own data in this guide is still being measured on real projects, with a single method. We will publish it with its sample size and date range once the sample is large enough; until then, every figure you see carries its source and date of consultation.

Sources

• https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=CELEX:32015R0751 — Regulation (EU) 2015/751, arts. 3 and 4: interchange fee caps of 0.2% (consumer debit) and 0.3% (consumer credit). Verified 08-27-2026.
• https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=CELEX:32018R0389 — Delegated Regulation (EU) 2018/389, art. 16 (low-value exemption: €30 per operation, €100 cumulative, five consecutive operations) and art. 18 (risk analysis, with reference fraud rates of 0.13% in remote card payments and 0.06% in transfers). Verified 08-27-2026.
• https://canales.redsys.es/canales/ayuda/documentacion/Manual%20integracion%20para%20conexion%20por%20Redireccion.pdf — Redirection integration manual: test URLs (sis-t.redsys.es:25443) and production (sis.redsys.es), HMAC_SHA256_V1 signature, Base64 Ds_MerchantParameters, 9-digit FUC, amount with last two positions as decimals, ISO-4217 978 currency, order number from 4 to 12 characters with the first four numeric, and response codes (0000-0099 authorized, 101 expired, 913 duplicate order, 9915 cancelled by user). Verified 08-27-2026.
• https://pagosonline.redsys.es/ — Virtual POS connection methods (redirection, InSite, REST/SOAP, modules for WooCommerce, PrestaShop, and Magento) and supported payment methods, including Bizum, Apple Pay, Google Pay, and PayPal. Verified 08-27-2026.
• https://stripe.com/es/pricing — Stripe rates in Spain: 1.5% + €0.25 on standard EEA cards, 2.8% + €0.25 on premium EEA cards, 3.15% + €0.25 on international cards, additional 2% for currency conversion, €20.00 per received dispute, €0.35 for SEPA debit. Verified 08-27-2026.
• https://stripe.com/es/pricing/local-payment-methods — Bizum commission on Stripe: 1.5% + €0.25 per charge. Verified 08-27-2026.
• https://docs.stripe.com/payments/bizum — Bizum on Stripe: minimum amount €0.50 and maximum €5,000, EUR only, no recurring payments, no manual capture, disputes open for up to 120 calendar days with 40 days to provide evidence and 90 days for resolution, total and partial refunds up to 395 days and asynchronous processing (up to 5 minutes), and list of excluded business categories. Verified 08-27-2026.
• https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740 — VAT Law 37/1992, consolidated text: art. 90 (general rate) and art. 20.One.18th (exemptions in financial operations), reference for the tax treatment of payment service commissions versus development.