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_SUCCEEDEDPAYIN_NORMAL_FAILED
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 isCONTESTABLE. 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 actualDisputeReasonType 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. |