Chapter 1. Two checkouts, not one Iberian checkout.

The Iberian Peninsula brings together two neighboring markets that call for two separate payment projects. A well-built Spanish checkout shows cards and Bizum, while a Portuguese checkout shows Multibanco references and MB WAY. The Spanish checkout rarely gets the rails wrong; the Portuguese one almost always does, because its rails have no equivalent anywhere else in Europe. Launching both countries with the same list means launching only one.

1,237M

Bizum transactions in 2025, up 13.2% year over year

Bizum, press release, January 2026

105.6M

online purchases paid with Bizum in 2025, up 82.1%

Bizum, press release, January 2026

85,2 %

card share of the total cleared through SICOI, Portugal’s interbank clearing system, in 2025

Banco de Portugal, Relatório dos Sistemas de Pagamentos 2025

>6.5M

MB WAY users, in a country of about 10 million people

SIBS, October 2025

Rail	Spain	Portugal	Launch decision
Visa and Mastercard cards	Required: domestic acceptance runs on the international brands	Required, but not sufficient on its own	Acquiring contract in both countries from the first order
Domestic wallet	Bizum, enabled on the acquiring contract, not integrated separately	MB WAY, with a dedicated key from the Portuguese PSP	Launch alongside cards, never in a second phase
Deferred account-to-account rail	Not applicable: Bizum confirms instantly	Multibanco references: the customer pushes the payment later	The longest workstream in Portugal: start it first
Cash at local stores	ATM network, no dedicated merchant rail	Payshop: cash payment at a local store counter	Launch if you target underbanked customers
Surcharge billed to the customer	Prohibited on instruments covered by Regulation (EU) 2015/751, under PSD2	Prohibited on every payment instrument: Decreto-Lei n.º 3/2010	Acceptance costs cannot be passed on. They are managed by steering the checkout flow

What an online merchant launches in each country, and in what order

Rank the list by the numbers, not by opinion

Two inputs are enough to set the display order: the share of orders each rail actually captures, and its fully loaded cost per order. Measure the share after three months of trading; no European average will give it to you. Read the cost from the contract, line by line, fixed fee included. A cheap rail in fifth position earns nothing, while an expensive rail at the top costs you every day.

Record the actual mix in the target country over three months, by order count and by value. The two rankings differ
Cost each rail at a constant average order value: fixed fee plus percentage fee, before any advertised commercial discount
Rank by ascending cost, then adjust: a rail with no chargebacks beats a slightly cheaper rail exposed to disputes
Put at the top the rail that combines the highest share with the lowest cost, and preselect it by default
Rerun the calculation after every acquirer renegotiation and every shift in average order value

⚠️

A payment list imported from another market

A store launched in the peninsula with another country’s payment list shows cards, one international wallet, and nothing else. In Spain, it gives up the share Bizum has won online: 105.6 million purchases in 2025, up 82.1% (Bizum, January 2026). In Portugal, the loss is heavier. Customers who find neither a Multibanco reference nor MB WAY don’t look for an equivalent. They close the tab.

The brands your customers recognize at checkoutBIBizumMUMultibancoMBMB WAYRERedsysSISIBSPAPayshop

🎯 Quick question

A Portuguese merchant wants to pass the cost of accepting a credit card on to the customer. What does Portuguese law say?

Chapter 2. Redsys and Spanish acquiring: the contract drives the code.

In Spain, merchants don’t choose their gateway. They choose their bank, and the gateway comes with it. Redsys Servicios de Procesamiento S.L., owned by Spanish banks and operating under that name since 2011, publishes the virtual terminal that nearly every acquirer resells under its own brand. The screens change color from one bank to the next, but the fields stay the same. That uniformity is a constraint at the start and an advantage later on.

The FUC, the merchant number assigned by the acquirer: it identifies the contract, not the website
One virtual terminal per channel: web, mobile app, back office, recurring. A single terminal lumps together flows that have neither the same approval rate nor the same fraud profile
The signing secret key and access to the test environment, obtained before the contract is finalized
Bizum activation on the contract, requested explicitly: not every business account offers it
The breakdown of merchant discount and interchange rates, subject to disclosure under Circular 1/2015 of the Banco de España, Spain’s central bank
The authorized server-to-server notification URL, and the procedure for changing it after go-live

Scope	Constraint	What breaks if you get it wrong
`Ds_Merchant_MerchantCode`	The FUC from the acquiring contract	A test FUC left in production makes every authorization fail, without exception
`Ds_Merchant_Terminal`	The contract’s terminal number, often `001` by default	Reporting mixes channels and makes per-channel approval rates unreadable
`Ds_Merchant_Order`	4 to 12 alphanumeric characters, unique	An identifier reused after a failure is rejected by the gateway, before it ever reaches the issuer
`Ds_Merchant_Amount`	Amount in the smallest currency unit: €51.30 is written `5130`	A hundredfold error on every transaction, discovered at the first settlement
`Ds_Merchant_Currency`	`978` for the euro (ISO 4217 code)	Rejected during testing, then time wasted on a trivial cause
`Ds_Merchant_TransactionType`	`0` for a standard authorization	A preauthorization nobody captures, and an order shipped without payment

The fields that make or break a Spanish integration (Redsys, TPV Virtual developer documentation, accessed August 2026)

Body of an authorization request, before minification, base64URL encoding, and signing

{
  "DS_MERCHANT_MERCHANTCODE": "<FUC assigned by the acquirer>",
  "DS_MERCHANT_TERMINAL": "002",
  "DS_MERCHANT_ORDER": "A26080142",
  "DS_MERCHANT_AMOUNT": "5130",
  "DS_MERCHANT_CURRENCY": "978",
  "DS_MERCHANT_TRANSACTIONTYPE": "0",
  "DS_MERCHANT_MERCHANTURL": "https://store.example/notify/redsys"
}

This block is never sent as is. It is minified, base64URL-encoded, and then signed, and the gateway verifies the signature before any processing (Redsys developer documentation, August 2026). A signature error therefore produces not an issuer decline but an upstream rejection, which shows up nowhere in approval statistics. Separating these two kinds of failure is the dashboard’s first job.

ℹ️

Multi-acquiring costs less in Spain than elsewhere

Because most banks resell the same gateway, adding a second Spanish acquirer is mostly a contract negotiation. The code barely changes: a new FUC, new terminals, a new key. This lever is rare in Europe, and it should be prepared before the first contract is signed. Testing, however, has to be redone in full, because each contract has its own terminals and its own permissions.

⚠️

A continuity plan that amounts to “switch PSPs” is not a plan

The Banco de España explicitly oversees Redsys and Cecabank as critical providers in the retail payments ecosystem, under article 4 of Real Decreto-ley 8/2023 (Memoria de Supervisión 2025). The regulator is formalizing what every integrator already sees: most of the market runs on very few platforms. A second Spanish acquirer offers no protection if the shared gateway goes down. Useful redundancy means an international PSP on separate infrastructure.

🎯 Quick question

After a failed payment, a store resends the same order to the Spanish gateway with the same identifier. What happens?

Chapter 3. Bizum: enabling, wiring, and testing.

Bizum is not a wallet. The underlying rail is a credit transfer. The payer designates the payee by phone number, the alias is resolved to an IBAN within the interbank infrastructure, and settlement runs through the SNCE, Spain’s national clearing system, operated by Iberpay. No card number changes hands, and there is no card chargeback. A back office that treats Bizum like a card will get disputes, refunds, and timing wrong.

Check that the business account offers it: this is almost always where things stall, and the blocker is commercial, not technical
Request activation on the FUC and on each relevant virtual terminal, channel by channel
Enable the payment method in the existing e-commerce module: Bizum is already there, with nothing extra to install
Test in the test environment, where a transaction cannot exceed €10 (Redsys developer documentation, August 2026)
Test in production with a real low-value transaction, then refund it, before showing the button
Check reconciliation: does settlement arrive on the same statement as cards, or in a separate feed?

The only code difference between a card request and a Bizum request

Ds_Merchant_Paymethods = "z"     <- lowercase, selects Bizum

The rest of the request is identical to a card transaction:
  FUC, terminal, order identifier, amount in the smallest unit,
  currency 978, server-to-server notification URL, signature.

Test environment: the transaction amount cannot exceed 10 EUR.

Source: Redsys, TPV Virtual developer documentation, accessed
August 2026.

	Card	Bizum
Type of payment	Authorization, then capture, on a card rail	Account-to-account transfer, cleared and settled through the SNCE
Customer dispute	Chargeback under Visa or Mastercard rules	No card chargeback: a transfer authorized by the account holder stays authorized
Refunds	Refund transaction provided for in the acquiring contract	Check the contract and test: the terms can’t be inferred from the card rail
Limits	Set by the issuer, rarely visible to the merchant	Scheme limits, adjustable by each member bank: a failure may stem from the payer’s own limit
Authentication	3-D Secure, with the exemptions provided under PSD2	Approval by the payer in their banking app
Diagnosing a failure	An issuer response code	Often no signal at all: the merchant sees an abandonment, not a decline

Bizum vs. cards: how the back office differs, and what must therefore be built differently

€67.7B

volume settled through Bizum in 2025, up 53.3%

Bizum, press release, January 2026

28 600

merchants and platforms connected to Bizum in 2025 alone

Bizum, press release, January 2026

30.6M

users at the end of 2025, against a stated target of 32.5 million for 2026

Bizum, press release, January 2026

One internal procedure point deserves to be written down. Bizum’s person-to-person service is not a business collection channel. Its limits are calibrated for private use, its reconciliation is manual, and it leaves the trail of a transfer between individuals. On October 17, 2025, the Spanish banking community and Iberpay launched the European Verification of Payee service required by Regulation (EU) 2024/886. Merchants that collect by credit transfer therefore have every reason to align the name they display with the actual account holder.

🔑

Bizum testing comes down to four pieces of evidence

A successful purchase, reconciled on the order identifier. A purchase that fails because the payer hits a limit, with a card fallback shown immediately. A refund processed and found on the statement. An end-of-day close in which the Bizum flow can be identified separately from the card flow. Without these four pieces of evidence, switching on the button leads to discrepancies that accounting will discover a month later.

🎯 Quick question

A Bizum integration is stalled in Spain. Where does the problem most often lie?

Chapter 4. Multibanco references: collecting without a checkout.

A referência Multibanco is a payment claim lodged in the Portuguese network, which the customer settles on their own initiative. The merchant gives the customer three values (entity, reference, amount) and then waits. The customer pays whenever they choose: at an ATM, in their banking app, or in MB WAY. Nothing is initiated by the merchant. Everything is initiated by the payer, and that changes the entire job.

What you get from your provider, and what to do with it

Entity       5 digits  assigned by SIBS to the code holder
Sub-entity   3 digits  assigned by the PSP to each of its merchants
                       segments the reference range
Reference    9 digits  issued by you or by the PSP
Amount                 CHECKED: a reference issued for EUR 51.30
                       cannot be paid with any other amount

DIRECT CONSEQUENCES
  - there is no way to change the amount after issue: cancel the
    reference and issue a new one
  - a malformed reference is rejected at entry, not at processing
  - the reconciliation key is the reference, never the bank description

Sources: ifthenpay, integration documentation, accessed August 2026;
SIBS for the assignment of entity codes.

State machine for an order paid by reference, on the merchant side

Status `created`

The order is recorded; inventory is reserved but not decremented

No payment exists yet. The order counts neither as revenue nor in the fulfillment queue

Status `reference issued`

The three values are requested from the provider, then shown to the customer

Entity, reference, amount, and an explicit deadline. This is the only point where the merchant can influence conversion

Status `pending`

The customer pays whenever they choose

A reminder on a set date, through the channel the customer provided, repeating the three values in plain text

Status `paid`

The server-to-server callback triggers fulfillment

The trigger is the provider’s notification. Not the display of the reference, and not an email from the customer

Status `expired`

The reference is invalidated and inventory is released

Without this transition, inventory stays locked in orders that will never be paid

Edge case to decide

What happens to a payment that arrives after your deadline?

Agree on the rule with the provider, then write it into the support procedure. Without it, every case is handled manually

Setting	Default to avoid	What to decide
Validity period	Unlimited	A short window speeds up cash flow and frees inventory; too short a window kills conversion. Measure the actual distribution of payment times first
Inventory reservation	Decrement at order time	Reserve without decrementing, and release automatically on expiry
Reminders	None	At least one reminder before the deadline, with the three values repeated in plain text in the message
Notification idempotency	Process every callback received	The same payment may be notified more than once. The deduplication key is the reference
Reconciliation	The bank entry’s description	The reference, and only the reference. The description is neither stable nor standardized

The five settings to lock down before issuing the first reference

That leaves the access model, which drives the project timeline. Getting your own entity code from SIBS, the setup used by large billers, gives you full control of the reference range but requires a direct contractual relationship. Going through a Portuguese provider that shares its code as sub-entities can be live in a few days. Nearly all e-commerce merchants choose this second route, which gets them live quickly, with the option to migrate later.

🔑

Your metrics no longer measure the same thing

On this rail, the authorization rate doesn’t exist and the checkout abandonment rate no longer means anything. Three metrics replace them: the conversion rate from issued references to paid references, the median time between issue and payment, and the share of expired references. The first measures the quality of the message sent to the customer. The second sizes the validity period and the cash position. The third quantifies inventory tied up for nothing. A team running this rail on a card dashboard is flying blind.

🎯 Quick question

Which event moves a Portuguese order paid by reference to “paid” status?

Chapter 5. MB WAY, acceptance costs, and payment timing.

MB WAY, the mobile side of the Portuguese network, launched by SIBS in 2015, has more than 6.5 million users in a country of about 10 million people (SIBS, October 2025). Customers identify themselves with their phone number and approve the payment in the app. On the merchant side, integration uses a dedicated key issued by the Portuguese provider (ifthenpay integration documentation, August 2026). The network is the same one that carries references. The timing is not.

Payment method	List price	Cost per order	As % of order value
MB WAY	0,07 € + 0,7 %	0,43 €	0,84 %
SEPA direct debit	€0.45 per transaction	0,45 €	0,88 %
Payshop	€0.57 per transaction	0,57 €	1,11 %
Multibanco references	0,20 € + 1,5 %	0,97 €	1,89 %
EEA consumer card	0,20 € + 1,5 %	0,97 €	1,89 %

Online acceptance costs in Portugal, based on the average card ticket of €51.30 (Banco de Portugal, 2025) and ifthenpay’s published rates (accessed August 2026)

Two lessons emerge from this table. Steering customers to MB WAY rather than cards saves €0.54 per order at this order value, or about €5,400 over 10,000 orders. The second lesson concerns flat-fee instruments: Payshop becomes cheaper than cards above roughly €24.70, and direct debit above €16.70. The break-even point takes one line to compute: set the flat fee equal to the card fee and solve for the amount. A store with a high average order value therefore needs a different ranking from one with small orders.

When the money arrives, and when it must go out

Cards: the payout delay is contractual, not regulatory. Negotiate it with the acquirer, then verify it against the first settlement statement
Multibanco reference: the collection date depends on the payer. It can’t be predicted order by order, but it can be predicted as a distribution, which is why you should measure that distribution before setting the validity period
Instant credit transfer: receiving has been mandatory since January 9, 2025, and sending since October 9, 2025, at the same price as a standard transfer (Regulation (EU) 2024/886)
Spanish card clearing: the banks have agreed that interbank settlement of domestic card activity will move to the SNCE (Banco de España, Memoria de Supervisión 2025). A change of infrastructure can shift value dates

	Spain	Portugal
Applicable law	Ley 3/2004, article 4, as amended by Ley 15/2010	Decreto-Lei n.º 62/2013, transposing Directive 2011/7/EU
Default term absent agreement	30 calendar days	30 days from receipt of the invoice
Maximum term agreed between businesses	60 calendar days	60 days, unless expressly agreed otherwise and not grossly unfair to the creditor
Public bodies	30 days	30 days, extended to 60 days for healthcare providers
Recovery compensation	Duly documented recovery costs	€40 minimum, with no prior formal notice
Late-payment interest	Due automatically on the due date	Due from the day after the due date, with no formal notice

B2B payment terms: two transpositions, two laws

✅

The only margin lever left

Neither country allows merchants to charge customers the cost of accepting common payment instruments. In Spain, PSD2 bans it for instruments covered by Regulation (EU) 2015/751; in Portugal, Decreto-Lei n.º 3/2010 bans it for every instrument. That leaves steering: preselecting the cheapest rail, its position in the list, and segmentation by order-value band. The effect of this configuration work is measured on the observed mix from one quarter to the next.

🎯 Quick question

A Portuguese rail costs €0.57 per transaction; cards cost €0.20 + 1.5%. Above what order value does the flat fee become cheaper?

Chapter 6. Declines, fraud, and degraded modes.

An Iberian payment performance dashboard that shows only an overall rate is useless, because failures come from four different places. Two are fixed in code; a third is negotiated and configured. The fourth can’t be fixed, because it belongs to the payer and never reaches the merchant.

Card type	Where it happens	What the merchant sees	Processing
Format or signature rejection	In the gateway, before the issuer	No trace at the issuer: the transaction never existed	Code: signature, encoding, uniqueness of the 4-to-12-character order identifier
Issuer decline	At the cardholder’s bank	A response code in the notification	Retry cascade, payment credential update, 3-D Secure trade-off
Authentication failure	During 3-D Secure	An abandonment in the flow, with no decline code	Quality of the data sent for authentication, choice of PSD2 exemptions
Payer limit or payer drop-off	In the customer’s banking app, on Bizum or MB WAY	Nothing at all: an undifferentiated abandonment	No technical fix. Show an immediate fallback and measure abandonment by rail

The four types of failure, and where to address them

One Spanish figure frames the exemption trade-off. In the second half of 2025, 19.1% of card payments were remote, but they accounted for 30% of value (Banco de España, H2 2025 payment statistics). Exposure is therefore concentrated in large orders, so an exemption policy calibrated on transaction count misses the risk. It must be calibrated on value.

fraudulent transactions per million card transactions in Portugal in the first half of 2025

Banco de Portugal, Relatório dos Sistemas de Pagamentos 2025

fraudulent transactions per million credit transfers, one-tenth the card rate

Banco de Portugal, Relatório dos Sistemas de Pagamentos 2025

84 %

share of transfer losses borne by customers in 2025

Banco de Portugal, Relatório dos Sistemas de Pagamentos 2025

54,5 %

share of card losses absorbed by institutions in 2025

Banco de Portugal, Relatório dos Sistemas de Pagamentos 2025

These last two figures drive a decision. Steering customers to an account-to-account rail lowers acceptance costs and eliminates chargebacks. The risk doesn’t disappear, though. It shifts to the payer. A merchant promoting Bizum or MB WAY must therefore expect complaints that no rulebook will resolve for it. The available safeguard is Verification of Payee, launched in Spain on October 17, 2025, under Regulation (EU) 2024/886.

⚠️

The April 28, 2025, outage has already answered the continuity question

The peninsula-wide blackout cut in-store card payments by 55% in Spain and Bizum transactions by 75% (Banco de España, Revista de Estabilidad Financiera No. 49, 2025). In Portugal, card purchases fell 36% during an outage of about 10 hours (Banco de Portugal, 2025). Neither rail served as a fallback for the other. The domestic rail, the cheapest one, is precisely the one that fell the most. A checkout steering policy is therefore no substitute for a continuity plan. The two are designed separately, and the continuity plan gets tested.

A terminal that can fail over to a mobile network independent of the checkout network
Backup power for the terminal and the router, sized in hours and tested
A written procedure for taking payments in degraded mode, with its limit and its risk-acceptance rule
Customer messaging prepared in advance: in Portugal, no surcharge can offset degraded payment acceptance
A plan sized for the rebound. On the Tuesday after the April 2025 outage, Spanish card spending was 14% higher than on non-holiday Tuesdays in April 2024 (Banco de España, 2025)

🎯 Quick question

A Portuguese merchant shifts part of its volume from cards to MB WAY. What effect on risk should it anticipate?

Chapter 7. E-invoicing and go-live.

In both countries, payment collection and the tax document are a single project. Catching up after go-live is expensive and ties up the same teams. Spain is currently layering two separate obligations that projects almost always confuse, while Portugal is completing a cycle that began 15 years ago. The two timetables look nothing alike, and neither can be inferred from the other.

January 1, 2026

Veri*factu, first wave

Companies subject to Spanish corporate income tax must use invoicing software that complies with Real Decreto 1007/2023, as amended by Real Decreto 254/2025.

July 1, 2026

Veri*factu, second wave

The remaining Spanish taxpayers come into scope. Businesses already on SII (Immediate Supply of Information) are exempt.

December 31, 2026

End of plain PDFs in Portugal

Portugal’s 2026 budget law extends until that date the acceptance of a plain PDF as an electronic invoice. The B2G obligation for micro, small, and medium-sized enterprises is postponed to the same date (Decreto-Lei n.º 13-A/2025).

January 1, 2027

Qualified signature and CIUS-PT

Portuguese invoices must carry a qualified electronic signature or seal. The structured CIUS-PT format becomes the norm.

2028

Portuguese accounting SAF-T

First mandatory filing, covering fiscal year 2026, after a postponement in the 2026 budget law.

Date not yet set

Spain’s ministerial order

The B2B e-invoicing mandate under Ley 18/2022 and Real Decreto 238/2026 starts 12 months after this order for companies with turnover above €8 million, and 24 months after it for the rest.

The planning consequence is clear. A Spanish timeline showing a firm date for the B2B mandate is announcing a date it doesn’t control, because the trigger is the order defining the public solution. The decree does not set that start date. The two Spanish regimes stack: Veri*factu governs the software, while Ley 18/2022 governs invoice exchange. Complying with one does not exempt you from the other.

Portugal, on every invoice: the unique document code ATCUD and a QR code on invoices and other tax-relevant documents
Portugal, every month: submission of the invoicing SAF-T (PT) to the Autoridade Tributária, the tax authority, by the 5th of the following month
Spain, accepted formats for B2B invoices: Facturae, UBL, CII, and EDIFACT, via the public solution of the AEAT (Spain’s tax agency) or a private platform
Cash, Spain: a €1,000 limit when either party is acting in a business capacity, €10,000 for a non-resident individual, and a penalty of 25% of the amount (Ley 11/2021, article 18)
Cash, Portugal: a €3,000 limit, €10,000 for a non-resident individual not acting as a business, and fines of €180 to €4,500 (Lei 92/2017)

Test case	Spain	Portugal	Required validation
Happy-path purchase	Card, on the web channel’s virtual terminal	Card, then MB WAY	Order set to paid by the server notification, never by the return page
Domestic wallet	Bizum enabled, real low-value transaction	MB WAY on a real Portuguese phone number	Payment found on the statement and matched on the order identifier
Deferred payment	Not applicable	Multibanco reference paid at an ATM	Inventory reserved at issue, decremented on notification
Expiration	Cart abandoned after an issuer decline	Unpaid reference reaching its expiry date	Inventory released, order canceled, customer notified
Refunds	Partial refund on card, then on Bizum	Refund of a paid reference	Accounting entry and tax document consistent with each other
Degraded mode	Simulated network outage on the terminal	Simulated network outage on the terminal	Written procedure followed, limit respected, recovery logged

Minimum test plan before launching the store

🔑

Go-live sequence

Start with Portugal, where the entity code or sub-entity, the reference state machine, and the document timetable sit on the critical path. Spain comes next, with a single planning risk: getting the bank to enable Bizum, which is neither automatic nor instant. Launching cards alone in both countries is still possible, but it means paying for traffic that the checkout won’t convert.

🎯 Quick question

What starts the 12-month and 24-month clocks for Spain’s B2B e-invoicing mandate?

Accepting payments in Spain and Portugal. 7 chapters and a final quiz.

Chapter 1. Two checkouts, not one Iberian checkout.

Rank the list by the numbers, not by opinion