Bizum

About

Bizum is a popular mobile payment method in Spain that integrates directly with the user’s banking app, enabling instant bank-to-bank transfers with just a phone number.

Region	Spain
Currencies	EUR
Refunds	Yes, within 365 days
Disputes	Yes, up to 120 days
Preauthorization	No
Recurring payments	No

How it works

1. User chooses payment method

   On your app or website, the user selects Bizum as the payment method.

2. Your platform initiates the pay-in

   You create the payment request by calling the POST Create a Bizum PayIn endpoint.

   If you send the user’s mobile phone number in the Phone parameter, then they receive a push notification from their banking app to authenticate the payment. In this case, no redirection is necessary.

   If you don’t have the user’s phone number, you must specify a ReturnURL and then redirect the user on the RedirectURL in the API response so that they can enter their phone number on a hosted screen.

3. User authenticates payment

   The user authenticates their payment in their banking app.

4. Your platform handles the outcome

   The pay-in Status changes from CREATED to SUCCEEDED or FAILED to indicate the outcome.

   You should also set up hook notifications for the relevant event types:

   • PAYIN_NORMAL_SUCCEEDED
   • PAYIN_NORMAL_FAILED

   When you receive the hook, call GET View a PayIn (Bizum) to confirm the outcome and, in case of failure, retrieve the ResultCode and ResultMessage for more information.

Disputes

A Bizum pay-in can be disputed by the user through their issuing bank. When this happens, Mangopay creates a Dispute object that is CONTESTABLE. You can be notified of this via the DISPUTE_CREATED webhook event type, and call GET View a Dispute for more information.

A user can open a dispute up to 120 days after the pay-in’s Status changed to SUCCEEDED (the ExecutionDate).

Once a dispute is open, your platform has 30 days to submit evidence. Once submitted, Bizum arbitrates the outcome within 15 days.

Dispute reasons

The reasons below may be given for a dispute. Note that the actual DisputeReasonType and DisputeReasonMessage may be different in wording.

Reason	Description
Not received	The service or product that should have been received in exchange for the payment has not been delivered to the user.
Defective	The service or product delivered does not correspond to the description or is in defective condition.
Duplicated	The transaction is duplicated.
Mismatched amounts	There are discrepancies between the authorized amount and the amount actually transferred.
Refund not processed	A refund was requested by the user but has not been received.
Already paid	The service or product was paid through other payment methods.
Refund error	A process error occurred in the case of a refund cancellation. For example, a user requested a refund and it was not processed correctly or was duplicated.
Unauthorized recurrence	The user canceled the subscription or scheduled payments, but the platform continued charging the user’s account despite the user’s cancellation notice.
Unrecognized, delayed, or amended	This reason is used when a separate transaction or additional charge is made without the user’s consent, exceeding the initial instruction.

Related resources

Endpoint

The Bizum PayIn object

Testing

Learn about testing Bizum