> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mangopay.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<table>
  <tbody>
    <tr>
      <th class="header">Region</th>

      <td class="table-content">
        Spain
      </td>
    </tr>

    <tr>
      <th class="header">Currencies</th>

      <td class="table-content">
        EUR
      </td>
    </tr>

    <tr>
      <th class="header">[Refunds](/guides/refunds)</th>

      <td class="table-content">
        Yes, within 365 days
      </td>
    </tr>

    <tr>
      <th class="header">[Disputes](#disputes)</th>

      <td class="table-content">
        Yes, up to 120 days
      </td>
    </tr>

    <tr>
      <th class="header">Preauthorization</th>

      <td class="table-content">
        No
      </td>
    </tr>

    <tr>
      <th class="header">Recurring payments</th>

      <td class="table-content">
        No
      </td>
    </tr>
  </tbody>
</table>

## How it works

<Steps>
  <Step title="User chooses payment method">
    On your app or website, the user selects Bizum as the payment method.
  </Step>

  <Step title="Your platform initiates the pay-in">
    You create the payment request by calling the [POST Create a Bizum PayIn](/api-reference/bizum/create-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.
  </Step>

  <Step title="User authenticates payment">
    The user authenticates their payment in their banking app.
  </Step>

  <Step title="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](/webhooks) for the relevant [event types](/webhooks/event-types):

    * `PAYIN_NORMAL_SUCCEEDED`
    * `PAYIN_NORMAL_FAILED`

    When you receive the hook, call [GET View a PayIn (Bizum)](/api-reference/bizum/view-payin-bizum) to confirm the outcome and, in case of failure, retrieve the `ResultCode` and `ResultMessage` for more information.
  </Step>
</Steps>

## 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](/webhooks/event-types#disputes), and call [GET View a Dispute](/api-reference/disputes/view-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.

<table>
  <thead>
    <tr>
      <th class="header">
        Reason
      </th>

      <th class="header">
        Description
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td class="table-content">
        Not received
      </td>

      <td class="table-content">
        The service or product that should have been received in exchange for the payment has not been delivered to the user.
      </td>
    </tr>

    <tr>
      <td class="table-content">
        Defective
      </td>

      <td class="table-content">
        The service or product delivered does not correspond to the description or is in defective condition.
      </td>
    </tr>

    <tr>
      <td class="table-content">
        Duplicated
      </td>

      <td class="table-content">
        The transaction is duplicated.
      </td>
    </tr>

    <tr>
      <td class="table-content">
        Mismatched amounts
      </td>

      <td class="table-content">
        There are discrepancies between the authorized amount and the amount actually transferred.
      </td>
    </tr>

    <tr>
      <td class="table-content">
        Refund not processed
      </td>

      <td class="table-content">
        A refund was requested by the user but has not been received.
      </td>
    </tr>

    <tr>
      <td class="table-content">
        Already paid
      </td>

      <td class="table-content">
        The service or product was paid through other payment methods.
      </td>
    </tr>

    <tr>
      <td class="table-content">
        Refund error
      </td>

      <td class="table-content">
        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.
      </td>
    </tr>

    <tr>
      <td class="table-content">
        Unauthorized recurrence
      </td>

      <td class="table-content">
        The user canceled the subscription or scheduled payments, but the platform continued charging the user's account despite the user's cancellation notice.
      </td>
    </tr>

    <tr>
      <td class="table-content">
        Unrecognized, delayed, or amended
      </td>

      <td class="table-content">
        This reason is used when a separate transaction or additional charge is made without the user's consent, exceeding the initial instruction.
      </td>
    </tr>
  </tbody>
</table>

## Related resources

<CardGroup col={2}>
  <Card title="Endpoint" href="/api-reference/bizum/bizum-payin-object">
    The Bizum PayIn object
  </Card>

  <Card title="Testing" href="/testing/payment-methods#bizum">
    Learn about testing Bizum
  </Card>
</CardGroup>