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

# Pre-quote a payout, for a confirm screen

> **Show the user what a payout will cost before they commit to it.** This is the confirm-screen endpoint: "you send 50,000 UGX, they receive 1,340 KES, fee 500" — priced by the real provider, with no money moved and nothing recorded as a transaction.

Optional. `POST /v1/payouts` re-quotes internally, so you never have to call this first; it exists purely so a UI can display a rate before the user taps send.

Returns OUR `quote_id` plus the human-meaningful fields. The provider's own quotation token NEVER leaves the gateway — holding it would let a caller go straight to the provider, bypassing our limits, idempotency and transaction records.

`expires_at` is ABSOLUTE and provider-reported. Do not assume a fixed TTL and do not hold a quote across a slow confirm screen — re-quote instead, or just send the payout and let the gateway price it.




## OpenAPI

````yaml /openapi.json post /v1/payouts/quote
openapi: 3.0.3
info:
  title: AptaPay Gateway
  version: 1.0.0
  description: >
    One provider-neutral payment API owned by many apps: collections, payouts,

    bank resolution and FX, with signed webhooks back.


    ## Authentication


    Every `/v1/*` request carries four headers. **A plain API key is not

    enough** — a key in a proxy log or an error report would be immediately

    usable, whereas a signature binds the request to a body and a moment.


    | Header | Value |

    | --- | --- |

    | `X-AptaPay-Key` | `{app_id}.{key_id}.{api_key}` |

    | `X-AptaPay-Timestamp` | unix seconds |

    | `X-AptaPay-Nonce` | 16-64 chars, `[A-Za-z0-9_-]`, unique per request |

    | `X-AptaPay-Signature` | `v1={hex HMAC-SHA256}` |


    The signature is HMAC-SHA256, with your **inbound** signing secret, over

    exactly these ten fields joined by `\n`:


    ```

    v1

    {APP_ID}

    {KEY_ID}

    {HOST}                      lowercased

    {METHOD}                    uppercased

    {PATH}                      no query, NOT url-decoded

    {CANONICAL_QUERY}           sorted, RFC3986-encoded, "" when absent

    {TIMESTAMP}

    {NONCE}

    {SHA256_HEX(RAW_BODY)}      sha256("") for GET/DELETE

    ```


    Every field earns its place. `CANONICAL_QUERY` is in there because without

    it `?limit=1` and `?limit=100000` sign identically, so a captured read

    signature could be replayed to dump everything. `HOST` stops a signature

    captured against one deployment replaying into another.


    The timestamp window is **asymmetric**: `-120s <= now - ts <= +30s`. A

    symmetric window is a ten-minute replay window, and there is no legitimate

    reason to sign in the future beyond small clock skew.


    A working reference implementation is in `docs/TENANT_INTEGRATION.md`, and

    `scripts/sign_request.mjs` signs a request from the terminal.


    ## Idempotency


    `Idempotency-Key` is **required** on every money-moving POST. A missing

    key is a 400 — the server never invents one, because a server-generated

    key is unique per request and protects nothing, which is worse than none

    because it looks like protection.


    - Replaying a completed key returns the **original response verbatim**,
      with its original status code. No second provider call.
    - The same key with **different parameters** is a 422, never a replay.

    - A concurrent duplicate is a 409 `request_in_progress`.


    ## Errors


    Branch on `error.code` and the three booleans, never on the HTTP status:

    `terminal` (reverse and tell the user), `retriable` (retry with the same

    key), `ambiguous` (**do not reverse** — poll instead).


    ## Amounts


    Integer minor units, with a per-currency exponent. **UGX, RWF, XAF and

    XOF are zero-decimal**: 2000 UGX is `2000`. Getting this wrong is a 100x

    error.


    ## Test mode is NOT a sandbox


    **Every request reaches a real provider. There is no sandbox, and no

    test host.** AptaPay routes to a single upstream provider, and that provider
    publishes

    exactly one API host for live and test traffic alike. No sandbox base URL

    exists anywhere in its reference documentation.


    So "test mode" here does not mean what it means on Stripe. It is a

    **second, real provider account** holding a small real balance, reached

    over the same wire as production. A test-mode payout moves real money out

    of a real wallet to a real phone number. It cannot be reversed, because

    the provider exposes no refund endpoint.


    | | What you might expect | What actually happens |

    | --- | --- | --- |

    | Host | a separate sandbox host | the one production host, always |

    | Money | simulated | real, in a real wallet |

    | Recipients | fake numbers accepted | real MSISDNs, really credited |

    | Undo | reverse the test charge | none — no refund endpoint exists |


    Two guardrails stand in for the sandbox, and they are permanent, not

    temporary scaffolding:


    - **A hard amount ceiling on every test-mode transaction**, enforced by
      this gateway *before* any provider call. Over it, you get a `422` and
      no request ever leaves.
    - **`is_test_mode` stamped on every transaction record**, so a test
      transaction is identifiable forever after the fact.

    Mode is a property of **which credentials you hold**, never of a request

    field — there is no `test: true` to send, and no header that switches it.

    A live key transacts live; that is the only thing that decides it. See

    `GET /healthz` for which mode a deployment is running.


    ## CORS


    There isn't any, deliberately. This is a server-to-server API and

    browsers must never call it: signing from client-side JS would put your

    secret in view-source. Cross-origin browser requests are denied.
servers:
  - url: https://api.pay.aptahq.com
    description: >-
      Production. There is no sandbox host, because the upstream provider has
      none — see "Test mode is NOT a sandbox". Sign the host you dial: the host
      is part of the canonical string, so a request dialled here must claim
      `api.pay.aptahq.com`.
security:
  - AptaPaySignature: []
tags:
  - name: Collections
    description: Money in.
  - name: Payouts
    description: Money out.
  - name: Refunds
    description: Reversals — 501 where the routed provider has no refund endpoint.
  - name: Transactions
    description: The gateway's own ledger of what it was asked to do.
  - name: Beneficiaries
    description: Saved recipients. Stored masked, names re-resolved at payout time.
  - name: Reference
    description: Corridors, banks, countries, balances, capability matrix.
  - name: Float
    description: Your own claim on the shared wallet pool — what you can actually pay out.
  - name: FX
    description: Exchange between your own wallets. Quote is free; exchange moves money.
  - name: Webhooks
    description: Provider ingress. Documented for completeness; tenants never call it.
  - name: Ops
    description: Health.
paths:
  /v1/payouts/quote:
    post:
      tags:
        - Payouts
      summary: Pre-quote a payout, for a confirm screen
      description: >
        **Show the user what a payout will cost before they commit to it.** This
        is the confirm-screen endpoint: "you send 50,000 UGX, they receive 1,340
        KES, fee 500" — priced by the real provider, with no money moved and
        nothing recorded as a transaction.


        Optional. `POST /v1/payouts` re-quotes internally, so you never have to
        call this first; it exists purely so a UI can display a rate before the
        user taps send.


        Returns OUR `quote_id` plus the human-meaningful fields. The provider's
        own quotation token NEVER leaves the gateway — holding it would let a
        caller go straight to the provider, bypassing our limits, idempotency
        and transaction records.


        `expires_at` is ABSOLUTE and provider-reported. Do not assume a fixed
        TTL and do not hold a quote across a slow confirm screen — re-quote
        instead, or just send the payout and let the gateway price it.
      operationId: quotePayout
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - amount_minor
                - currency
                - country
                - method
                - destination
              properties:
                amount_minor:
                  $ref: '#/components/schemas/MinorUnits'
                currency:
                  $ref: '#/components/schemas/Currency'
                destination_currency:
                  $ref: '#/components/schemas/Currency'
                country:
                  type: string
                method:
                  type: string
                  enum:
                    - momo
                    - bank
                    - eversend
                destination:
                  $ref: '#/components/schemas/PayoutDestination'
                amount_type:
                  type: string
                  enum:
                    - SOURCE
                    - DESTINATION
            example:
              amount_minor: 50000
              currency: UGX
              destination_currency: UGX
              country: UG
              method: momo
              destination:
                type: momo
                msisdn: '+256781234567'
                network: MTN
                country: UG
      responses:
        '200':
          description: >
            A quote. Note `expires_at` is ABSOLUTE and provider-reported — do
            not assume a fixed TTL, and re-quote rather than replaying a stale
            one.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/APIResult'
        '400':
          $ref: '#/components/responses/BadRequest'
        '401':
          $ref: '#/components/responses/Unauthorized'
components:
  schemas:
    MinorUnits:
      type: integer
      description: >
        An integer count of the currency's smallest unit. NEVER a float, and

        never a decimal major amount. The `_minor` suffix on a field name is
        part

        of the contract: `amount` could be read as `20.00` or `2000`, whereas

        `amount_minor` can only be read one way.


        **The exponent is PER CURRENCY.** There is no universal "cents":


        | Exponent | Currencies | `2000` means |

        |---|---|---|

        | **0** (zero-decimal) | UGX, RWF, XAF, XOF | 2,000 shillings/francs |

        | **2** | KES, GHS, NGN, TZS, ZMW, USD, EUR, GBP | 20.00 |


        So `2000` UGX is two thousand shillings, while `2000` KES is twenty.

        Applying a blanket x100 to a zero-decimal currency is a **100x money

        error** — the kind that reconciles to nothing months later.


        To send an amount, multiply the major amount by `10^exponent` and
        confirm

        the result is an exact integer (KES `19.99` -> `1999`). To display one,

        divide by `10^exponent` for presentation only — keep the minor-unit

        integer as the value you store, compare, and sum.


        Rules the gateway enforces:


        - **An unknown currency is rejected, never defaulted.** A currency with
          no declared exponent fails with `unknown_currency` rather than assuming
          2, because a silent wrong exponent is worse than a loud failure.
        - **A non-exact amount is rejected, never rounded.** KES `19.999` fails
          with `inexact_amount`. AptaPay will not decide on your behalf which way
          to round someone's money.
        - **Amounts are never floats internally.** Providers send amounts as
          strings (`"2000"`) AND sometimes as numbers, so parsing is deliberate
          at the adapter boundary and converts to an exact integer or fails.

        A field's exponent always follows the currency named alongside it. On an

        FX quote, `source_amount_minor` and `destination_amount_minor` routinely

        use DIFFERENT exponents in the same response.
      example: 2000
    Currency:
      type: string
      enum:
        - UGX
        - RWF
        - XAF
        - XOF
        - KES
        - GHS
        - NGN
        - TZS
        - ZMW
        - USD
        - EUR
        - GBP
    PayoutDestination:
      oneOf:
        - $ref: '#/components/schemas/PayoutMomoDestination'
        - $ref: '#/components/schemas/BankDestination'
      discriminator:
        propertyName: type
    APIResult:
      type: object
      description: >
        The single response envelope, used by EVERY endpoint so a consuming app
        parses one shape everywhere.
      required:
        - code
        - message
      properties:
        code:
          type: integer
          example: 200
        message:
          type: string
          example: OK
        data:
          description: Present on success. Shape varies per endpoint.
        error:
          $ref: '#/components/schemas/GatewayErrorBody'
    PayoutMomoDestination:
      type: object
      description: >
        A momo destination on a PAYOUT. `country` is REQUIRED and is NOT
        inherited from the request's top-level `country`.


        A payout pushes money to whoever answers that number, and once it lands
        it cannot be recalled. The field that decides which country's subscriber
        is paid must therefore be stated explicitly on the leg that spends the
        money, never defaulted from a field set for another reason.
      required:
        - type
        - msisdn
        - country
      properties:
        type:
          type: string
          enum:
            - momo
        msisdn:
          type: string
          description: >
            The customer's phone number in whatever form they typed it. All of
            `0772123456`, `256772123456`, `+256772123456` and the bare national
            `772123456` are accepted, with spaces, dashes and parentheses
            ignored. The platform normalises to E.164 WITH the leading `+`
            (`+256772123456`) using the country code of the resolved corridor —
            so a missing country code is supplied, never guessed from the
            digits.

            The number is validated AGAINST the corridor: one carrying a
            different country's calling code, or the wrong national length, is
            rejected with `invalid_msisdn` rather than reinterpreted.
          example: '0772123456'
        network:
          type: string
          description: >
            Network code, a free string from the corridor table — never a closed
            enum, so a network can be added in Firestore with no schema change.
          example: MTN
        country:
          type: string
          description: >
            REQUIRED. Not inherited from the top-level `country`; the number is
            validated against it, so a mismatch is rejected.
          example: UG
    BankDestination:
      type: object
      required:
        - type
        - country
        - bank_code
        - account_number
      properties:
        type:
          type: string
          enum:
            - bank
        country:
          type: string
          example: NG
        bank_code:
          type: string
          example: '044'
        bank_name:
          type: string
        account_number:
          type: string
          example: '0011223344'
        account_name:
          type: string
          description: >
            Advisory only. The gateway RE-RESOLVES the account name at payout
            time, every time — a stale "yes, this is Jane Doe" can outlive the
            account being closed, renamed, or reassigned.
        msisdn:
          type: string
          example: '+256763494235'
          description: >
            The RECIPIENT's phone number. Not needed to reach the account, but
            the upstream provider REQUIRES a contact number on bank payouts and
            rejects an empty one — so a bank payout routed upstream without this
            is refused as `validation_failed` naming `destination.msisdn`.
            Accepted in local format (`0763494235`) and normalised to E.164
            against `destination.country`.
    GatewayErrorBody:
      type: object
      description: >
        Machine-readable error classification. EXACTLY ONE of
        terminal/retriable/ ambiguous is true.

        laces_api inferred this from the HTTP status and got it wrong, stranding
        real money twice (2026-08-15, 2026-08-16). Branch on these booleans,
        never on the status code:

          terminal  -> the provider refused. Reverse the debit and tell the user.
          retriable -> safe to retry with the SAME Idempotency-Key.
          ambiguous -> the outcome is UNKNOWN. Do NOT reverse. Poll instead.
      required:
        - code
        - message
        - terminal
        - retriable
        - ambiguous
      properties:
        code:
          type: string
          description: Stable machine code. Branch on this, never on `message`.
          example: payout_rejected_by_provider
        message:
          type: string
          description: >
            Human text from a compiled-in map. NEVER provider text — a
            stringified provider error can carry an Authorization header.
        terminal:
          type: boolean
        retriable:
          type: boolean
        ambiguous:
          type: boolean
        details:
          type: object
          additionalProperties:
            type: string
  responses:
    BadRequest:
      description: Validation failed.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/APIResult'
    Unauthorized:
      description: >
        Missing, malformed, stale, replayed or invalid signature. Also returned
        when a body was sent but its raw bytes were unavailable —
        verified-as-empty must never mean processed-as-full.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/APIResult'
  securitySchemes:
    AptaPaySignature:
      type: apiKey
      in: header
      name: X-AptaPay-Signature
      description: >
        `v1={hex HMAC-SHA256}` over the ten-field canonical string. Sent
        alongside `X-AptaPay-Key`, `X-AptaPay-Timestamp` and `X-AptaPay-Nonce` —
        all four are required. OpenAPI can only model one header per scheme, so
        the other three are described in the Authentication section above.

````