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
User chooses payment method
On your app or website, the user selects Bizum as the payment method.
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.
User authenticates payment
The user authenticates their payment in their banking app.
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_SUCCEEDEDPAYIN_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. |