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

# Charges overview

> The ways to collect money from your customers, and how to choose between them.

A **charge** is how you collect money from a customer. Zerocash offers several charge methods, one
per payment rail, so you can pick the ones your market actually uses.

## Which method should I use?

| Method                                                  | Use this when                                             | Customer action                                               | Best for                             |
| :------------------------------------------------------ | :-------------------------------------------------------- | :------------------------------------------------------------ | :----------------------------------- |
| [Mobile Money Charge](/guides/collections/mobile-money) | You already know the phone number, currency, and operator | Approves an STK, OTP, USSD, redirect, or provider prompt      | Direct mobile money collections      |
| [Bank Transfer](/guides/collections/bank-transfer)      | You want a temporary account for an exact bank transfer   | Sends the exact amount before the account expires             | NGN or KES bank-transfer collections |
| [OPay Charge](/guides/collections/opay)                 | You want to accept NGN payments through OPay              | May be redirected to complete authorisation                   | Nigeria OPay-specific checkout flows |
| [Card Charge](/guides/collections/card)                 | You collect card details server-side                      | May complete 3DS, OTP, PIN, redirect, or address verification | Card checkout flows                  |

<Tip>
  If you are unsure, start with **mobile money**. It has the widest market coverage of any single
  method, and the transaction handling you build for it — unique references, webhooks, confirming
  before you fulfil — is identical for every other method you add later.
</Tip>

## The happy path

Every charge method follows the same five beats.

<Steps>
  <Step title="Pick the method">
    Choose the charge method that matches the checkout experience you want.
  </Step>

  <Step title="Initiate the charge">
    Call the endpoint with a unique `externalReference`. You get back a `transactionId`.
  </Step>

  <Step title="Show the customer their next action">
    A temporary account, an STK prompt, or a redirect URL — depending on the method.
  </Step>

  <Step title="Wait for the outcome">
    Listen for [webhooks](/guides/webhooks/getting-started), or poll
    [Get Transaction](/api-reference/endpoint/get-transaction).
  </Step>

  <Step title="Provide value">
    Only once the final transaction status is `successful`.
  </Step>
</Steps>

<Warning>
  A `200` from a charge endpoint means the request was **accepted**, not that the customer paid.
  Fulfilling on the initial response is the single most common integration mistake.
</Warning>

## Mid-charge steps

Charges do not always complete in one call. When a transaction needs the customer to do something
else, the response or webhook carries a `stepRequired` field.

| `stepRequired`         | Meaning                               | What you do                                                                |
| :--------------------- | :------------------------------------ | :------------------------------------------------------------------------- |
| `otp`                  | The operator sent the customer a code | Collect it, submit to [Validate OTP](/api-reference/endpoint/validate-otp) |
| `redirect`             | The customer must authorise off-site  | Send them to the returned `redirectUrl`                                    |
| `pin`                  | Card PIN required                     | Submit via [Authorise Charge](/api-reference/endpoint/authorise-charge)    |
| `address_verification` | Billing address must be verified      | Submit via [Authorise Charge](/api-reference/endpoint/authorise-charge)    |

After any of these, the transaction keeps processing in the background. Wait for the final
`successful` or `failed` webhook.

## Refunds

A previously successful **mobile money** deposit can be refunded through
[Refund Deposit](/api-reference/endpoint/refund-deposit). This is useful for customer refunds and
for correcting erroneous charges.

<Note>
  Refunds are available for mobile money transactions only.
</Note>

## Before you build

<CardGroup cols={2}>
  <Card title="Supported countries & limits" icon="globe" href="/guides/supported-countries">
    Check the corridors you need are live, and what the per-transaction limits are.
  </Card>

  <Card title="Mobile money operators" icon="mobile" href="/guides/mobile-money-operators">
    Operator codes by country — required for every currency except `KES`.
  </Card>
</CardGroup>