​
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.
RegionSpain
CurrenciesEUR
RefundsYes, within 365 days
DisputesYes, up to 120 days
PreauthorizationNo
Recurring paymentsNo

​
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.
ReasonDescription
Not receivedThe service or product that should have been received in exchange for the payment has not been delivered to the user.
DefectiveThe service or product delivered does not correspond to the description or is in defective condition.
DuplicatedThe transaction is duplicated.
Mismatched amountsThere are discrepancies between the authorized amount and the amount actually transferred.
Refund not processedA refund was requested by the user but has not been received.
Already paidThe service or product was paid through other payment methods.
Refund errorA 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 recurrenceThe 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 amendedThis reason is used when a separate transaction or additional charge is made without the user’s consent, exceeding the initial instruction.

Endpoint

The Bizum PayIn object

Testing

Learn about testing Bizum