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

# Verify phone ownership: flip PENDING_PROOF → VERIFIED with atomic side-effect resolution

> Step 2 of cashier signup: verify phone ownership and transition the customer's wallet identity from `PENDING_PROOF` to `VERIFIED`. The customer clicks the SMS link (or the cashier keys the code); the service decodes the signed verification token, guards that it is not-expired, not-consumed, and that its wallet identity is still `PENDING_PROOF`, then in ONE transaction flips the state to `VERIFIED` and resolves ALL deferred side-effects atomically: (1) create the provider-customer link binding the POS provider's customer id to the wallet identity, (2) bind the customer to their canonical wallet (find-or-create at credit time), (3) RELEASE any `LOCKED` cashback-class promotional grants escrowed against the proto-wallet via the claim-gate (so the customer keeps the reload plus the now-released bonus), and (4) arm marketing/offers eligibility. **None of these resolve partially**: if any step fails the whole flip rolls back and the link stays consumable. Idempotent: a re-submit of an already-consumed token replays the original verified result (`meta.idempotency_replayed:true`) and does NOT re-release grants. A token for a wallet identity owned by another integration returns `403`. The claim release engine is itself the `POST /claims` resource; this endpoint INVOKES it inline for the common path, while `/claims` is the explicit ops re-drive.



## OpenAPI

````yaml /api-reference/openapi.yaml post /enroll/verify
openapi: 3.1.0
info:
  title: Feddi Partner API
  version: '2026-06-01'
  description: >-
    Operate a Feddi closed-loop wallet and loyalty program at the point of sale:
    identify customers, read balances, accept wallet payments, run top-ups, and
    reconcile transactions.


    All amounts are integer minor units with an explicit ISO-4217 currency.
    Balances are merchant-held and closed-loop.


    Every response uses a typed envelope (`ok` / `data` / `error` / `meta`) with
    string error codes (never a bare HTTP number) and an idempotency-replay
    flag. Authenticate with the `x-api-key` header; exchange it for a
    short-lived POS terminal JWT for hot-path calls.


    Self-validate against this document (`GET /openapi`) and read `GET
    /capabilities` for the credential types, currencies, and features enabled
    for your integration before assuming any enum.


    Operations are tagged `x-feddi-availability: ga` (stable) or `beta`
    (callable, contract may still change additively); confirm what is enabled
    for your credentials via `GET /capabilities`.


    Sandbox access is granted per partner agreement; request credentials from
    your Feddi contact.
servers:
  - url: https://api.feddi.io/v1/partner
    description: production
  - url: https://api.dev.feddi.io/v1/partner
    description: dev
security:
  - ApiKeyAuth: []
tags:
  - name: platform
    description: >-
      Platform cross-cutting: health, capabilities, openapi self-serve, merchant
      provisioning, settlement, reconciliation.
  - name: checkout_session
    description: >-
      Checkout sessions: every interaction opens a session, then identity and
      basket attach to it, and payment, top-up, and offers run against it.
  - name: auth
    description: >-
      Partner authentication + onboarding: API key lifecycle, POS terminal JWT
      exchange, terminal heartbeat.
  - name: customers
    description: >-
      Customer lookup + identification: resolve identity, cashier-panel
      summaries, preferences, GDPR export/erase.
  - name: enrollment
    description: >-
      Enrollment + signup: OTP enroll, cashback claims, identity/consent,
      customer correction + merge.
  - name: payments
    description: >-
      Payments + redemption: debit wallet (promo-first), balance-check, void,
      refund, QR mint.
  - name: topup
    description: >-
      Wallet top-up: 2-step prepare/confirm, reload-bonus grants, SKU top-up,
      settlement + reconciliation.
  - name: incentives
    description: >-
      Incentives + offers: offer feeds, apply/redeem/release locks, proposals,
      budget envelopes, points, grant clawback.
  - name: transactions
    description: >-
      Transactions + receipts: transaction detail, void, receipts, disputes,
      settlements, reconciliation, exports.
  - name: webhooks
    description: >-
      Webhooks + events: subscriptions, delivery history + retry, event catalog,
      polling fallback.
paths:
  /enroll/verify:
    post:
      tags:
        - enrollment
      summary: >-
        Verify phone ownership: flip PENDING_PROOF → VERIFIED with atomic
        side-effect resolution
      description: >-
        Step 2 of cashier signup: verify phone ownership and transition the
        customer's wallet identity from `PENDING_PROOF` to `VERIFIED`. The
        customer clicks the SMS link (or the cashier keys the code); the service
        decodes the signed verification token, guards that it is not-expired,
        not-consumed, and that its wallet identity is still `PENDING_PROOF`,
        then in ONE transaction flips the state to `VERIFIED` and resolves ALL
        deferred side-effects atomically: (1) create the provider-customer link
        binding the POS provider's customer id to the wallet identity, (2) bind
        the customer to their canonical wallet (find-or-create at credit time),
        (3) RELEASE any `LOCKED` cashback-class promotional grants escrowed
        against the proto-wallet via the claim-gate (so the customer keeps the
        reload plus the now-released bonus), and (4) arm marketing/offers
        eligibility. **None of these resolve partially**: if any step fails the
        whole flip rolls back and the link stays consumable. Idempotent: a
        re-submit of an already-consumed token replays the original verified
        result (`meta.idempotency_replayed:true`) and does NOT re-release
        grants. A token for a wallet identity owned by another integration
        returns `403`. The claim release engine is itself the `POST /claims`
        resource; this endpoint INVOKES it inline for the common path, while
        `/claims` is the explicit ops re-drive.
      operationId: enrollVerify
      parameters:
        - $ref: '#/components/parameters/IdempotencyKey'
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/EnrollVerifyRequest'
            example:
              meta:
                partner_request_id: 2b3c4d5e-0002-4f9b-9d1e-1a2b3c4d5e6f
                occurred_at: '2026-06-05T09:45:00Z'
                sent_at: '2026-06-05T09:45:01Z'
                api_version: '2026-06-01'
              context:
                merchant_id: 11111111-1111-1111-1111-111111111111
                branch_id: 22222222-2222-2222-2222-222222222222
                terminal_id: POS-360-0007
              verification_token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.proof.signature
              code: null
      responses:
        '200':
          description: >-
            Phone ownership proven; wallet identity is now VERIFIED, all
            side-effects resolved in one transaction (or idempotent replay of a
            prior verify).
          content:
            application/json:
              schema:
                allOf:
                  - $ref: '#/components/schemas/ResponseEnvelope'
                  - type: object
                    properties:
                      data:
                        $ref: '#/components/schemas/EnrollVerifyResult'
              example:
                ok: true
                data:
                  wallet_user_id: wu_aa01
                  customer_state: verified
                  verified_at: '2026-06-05T09:45:02Z'
                  wallet_id: wal_5512
                  wallet_program_id: wp_77
                  provider_customer_map_created: true
                  balance_minor: 5000
                  promo_balance_minor: 250
                  currency: QAR
                  released_grants:
                    - promo_grant_id: pg_bb02
                      released_minor: 250
                      source: SKU_TOPUP_BONUS
                error: null
                meta:
                  request_id: req_ev1
                  idempotency_replayed: false
                  api_version: '2026-06-01'
                  data_completeness_score: 78
        '400':
          description: >-
            `VALIDATION_ERROR` (HTTP 400), malformed body, missing token/code,
            or a domain rule violated. `details` carries the field errors.
          content:
            application/json:
              schema:
                allOf:
                  - $ref: '#/components/schemas/ResponseEnvelope'
                  - type: object
                    properties:
                      error:
                        $ref: '#/components/schemas/Error'
        '401':
          description: >-
            `INVALID_API_KEY` (HTTP 401), missing/invalid `x-api-key` or POS
            terminal JWT.
          content:
            application/json:
              schema:
                allOf:
                  - $ref: '#/components/schemas/ResponseEnvelope'
                  - type: object
                    properties:
                      error:
                        $ref: '#/components/schemas/Error'
        '403':
          description: >-
            `FORBIDDEN` (HTTP 403), the verification token belongs to a wallet
            identity owned by another integration (cross-tenant), or wrong
            wallet.
          content:
            application/json:
              schema:
                allOf:
                  - $ref: '#/components/schemas/ResponseEnvelope'
                  - type: object
                    properties:
                      error:
                        $ref: '#/components/schemas/Error'
        '404':
          description: >-
            `NOT_FOUND`, the token does not resolve to a PENDING_PROOF wallet
            identity for this integration.
          content:
            application/json:
              schema:
                allOf:
                  - $ref: '#/components/schemas/ResponseEnvelope'
                  - type: object
                    properties:
                      error:
                        $ref: '#/components/schemas/Error'
        '422':
          description: >-
            `VALIDATION_ERROR`, the token is expired, the wallet identity
            already left PENDING_PROOF in a non-idempotent way, or
            `IDEMPOTENCY_KEY_REUSED`. A genuinely already-consumed token of THIS
            verify returns 200 with `idempotency_replayed:true`, not 422.
          content:
            application/json:
              schema:
                allOf:
                  - $ref: '#/components/schemas/ResponseEnvelope'
                  - type: object
                    properties:
                      error:
                        $ref: '#/components/schemas/Error'
      security:
        - PosTerminalJWT: []
components:
  parameters:
    IdempotencyKey:
      name: Idempotency-Key
      in: header
      required: true
      description: >-
        Partner-generated UUID; the ONE dedup key for all mutating endpoints.
        24h TTL. Same key + same payload -> byte-identical replay; same key +
        different payload -> IDEMPOTENCY_KEY_REUSED (422).
      schema:
        type: string
        format: uuid
  schemas:
    EnrollVerifyRequest:
      type: object
      description: >-
        Body for POST /enroll/verify. Supply EXACTLY ONE of the signed token
        (SMS link) or the keyed code, enforced by the `oneOf` below (a body
        carrying both, or neither, is invalid).
      required:
        - context
      properties:
        meta:
          $ref: '#/components/schemas/RequestMeta'
        context:
          $ref: '#/components/schemas/RequestContext'
        verification_token:
          type:
            - string
            - 'null'
          description: >-
            The signed single-use token from the SMS link. Provide this OR
            `code`, never both.
        code:
          type:
            - string
            - 'null'
          pattern: ^[0-9]{6}$
          description: >-
            The 6-digit numeric code the cashier keyed (alternative to the link
            token). Exactly 6 ASCII digits.
          example: '482913'
      oneOf:
        - required:
            - verification_token
          properties:
            verification_token:
              type: string
            code:
              type: 'null'
        - required:
            - code
          properties:
            code:
              type: string
            verification_token:
              type: 'null'
    ResponseEnvelope:
      type: object
      description: >-
        The standard response envelope that every enveloped endpoint serializes
        through. `ok` is a boolean discriminator: when `ok` is `true`, the typed
        result is carried in `data`; when `ok` is `false`, a typed error object
        is returned instead. The `meta` object is uniform across the entire API
        surface.
      required:
        - ok
        - meta
      properties:
        ok:
          type: boolean
        data:
          type:
            - object
            - 'null'
        error:
          oneOf:
            - $ref: '#/components/schemas/Error'
            - type: 'null'
        meta:
          $ref: '#/components/schemas/Meta'
    EnrollVerifyResult:
      type: object
      description: >-
        Result of a successful `POST /enroll/verify` request. Returned when the
        submitted one-time passcode is accepted, confirming the customer's
        wallet identity and transitioning its enrollment state to `VERIFIED`.
        Once this result is returned, the wallet identity is active and eligible
        for subsequent wallet operations.
      required:
        - wallet_user_id
        - customer_state
      properties:
        wallet_user_id:
          type: string
        customer_state:
          type: string
          enum:
            - verified
          description: Always verified on success (or idempotent replay of a prior verify).
        verified_at:
          type: string
          format: date-time
        wallet_id:
          type:
            - string
            - 'null'
          description: The canonical wallet bridged at verify.
        wallet_program_id:
          type:
            - string
            - 'null'
        provider_customer_map_created:
          type: boolean
          description: >-
            Whether a new provider-customer link was created (false on a
            replay).
        balance_minor:
          type:
            - integer
            - 'null'
          description: >-
            Actual cashable balance after any escrowed credit was applied, minor
            units.
        promo_balance_minor:
          type:
            - integer
            - 'null'
          description: >-
            RELEASED promo balance after any escrowed grants were released,
            minor units.
        currency:
          type:
            - string
            - 'null'
        released_grants:
          type: array
          description: >-
            The LOCKED grants released by this verify (empty if none were
            escrowed).
          items:
            $ref: '#/components/schemas/ReleasedGrant'
    Error:
      type: object
      description: >-
        The typed error object returned with every non-2xx response. `code` is a
        string enum (for example `WALLET_PROGRAM_AMBIGUOUS`,
        `CREDENTIAL_TYPE_UNSUPPORTED`, `INSUFFICIENT_FUNDS`,
        `IDEMPOTENCY_KEY_REUSED`, `CURRENCY_NOT_SUPPORTED`), **never a bare HTTP
        status number**. Inspect `code` for programmatic branching, not the HTTP
        status. Some codes echo the valid set in `details` so clients can
        present or reconcile the accepted values: for example
        `CREDENTIAL_TYPE_UNSUPPORTED` lists the supported credential types,
        `CURRENCY_NOT_SUPPORTED` lists the supported ISO-4217 currencies, and
        `WALLET_PROGRAM_AMBIGUOUS` lists the candidate `wallet_program_id`
        values that matched the request.
      required:
        - code
        - message
      properties:
        code:
          type: string
          enum:
            - INSUFFICIENT_FUNDS
            - INVALID_API_KEY
            - CREDENTIAL_TYPE_UNSUPPORTED
            - CURRENCY_NOT_SUPPORTED
            - IDEMPOTENCY_KEY_REUSED
            - WALLET_PROGRAM_AMBIGUOUS
            - REQUIRES_DYNAMIC_CREDENTIAL
            - NOT_FOUND
            - FORBIDDEN
            - VALIDATION_ERROR
            - RATE_LIMITED
            - CONFLICT
            - INTERNAL_SERVER_ERROR
        message:
          type: string
        details:
          type: object
          additionalProperties: true
    RequestMeta:
      type: object
      description: >-
        Common request metadata shared across all Partner API domains.
        `partner_request_id` is a correlation identifier only: it appears in
        logs and responses for tracing but is **never used as the deduplication
        key**. Request deduplication is keyed exclusively on the
        `Idempotency-Key` header.
      required:
        - partner_request_id
        - api_version
      properties:
        partner_request_id:
          type: string
          format: uuid
          description: Partner's own correlation id. NOT the idempotency basis.
        occurred_at:
          type: string
          format: date-time
          description: >-
            When the event happened at the POS (RFC3339). Clock-drift signal vs
            sent_at.
        sent_at:
          type: string
          format: date-time
          description: When the partner sent the request (RFC3339).
        api_version:
          type: string
          description: The single API version field.
          example: '2026-06-01'
    RequestContext:
      type: object
      description: >-
        Canonical request context, shared across all partner domains.
        `merchant_id` is key-enforced to a merchant the calling credential is
        authorized for (a platform-scoped credential acts only on its own
        tenants), so it is **never a free-text trust field**: a `merchant_id`
        outside the credential's authority is rejected rather than honored.
      required:
        - merchant_id
      properties:
        merchant_id:
          type: string
          format: uuid
          description: Resolved Feddi tenant (enterprise).
        branch_id:
          type:
            - string
            - 'null'
          format: uuid
        terminal_id:
          type:
            - string
            - 'null'
        cashier_id:
          type:
            - string
            - 'null'
          description: Server-trusted only when signed into the terminal JWT.
        partner_session_id:
          type:
            - string
            - 'null'
          description: The partner's own order/session ref.
        feddi_session_id:
          type:
            - string
            - 'null'
          format: uuid
          description: >-
            The checkout_session this call anchors to. On session sub-resource
            calls it is redundant with the path `{id}` and must match it.
    Meta:
      type: object
      description: >-
        The uniform response metadata block returned on every response.
        `data_completeness_score` is computed per call and reports the
        completeness of the returned data. `decision_trace_id` is present on
        responses that carry decision or insight output and can be used to
        correlate the response with its reasoning. `capabilities` is an
        additive, response-level array of hints advertising features the caller
        may use, and may be extended over time without notice.
      required:
        - request_id
        - api_version
      properties:
        request_id:
          type: string
          description: Feddi-issued correlation id for this response.
        idempotency_replayed:
          type: boolean
          description: True when this response was replayed from the idempotency store.
        api_version:
          type: string
          description: The single API version field.
          example: '2026-06-01'
        data_completeness_score:
          type: integer
          minimum: 0
          maximum: 100
          description: >-
            0-100, computed per call (basket/identity/tax/category/consent
            presence).
        decision_trace_id:
          type:
            - string
            - 'null'
          description: Opaque trace id on intelligence-bearing responses; one per response.
        capabilities:
          type: object
          additionalProperties: true
          description: Additive response-level capability hints.
    ReleasedGrant:
      type: object
      description: >-
        A single promotional grant released (or carried forward) as the result
        of a claim or verify operation. Promotional balances can expire and are
        **never cashable**: they may only be spent, not withdrawn or refunded as
        cash.
      required:
        - promo_grant_id
        - released_minor
      properties:
        promo_grant_id:
          type: string
          description: The promotional grant ledger row id.
        released_minor:
          type: integer
          description: Promo amount released to spendable, minor units.
        source:
          type:
            - string
            - 'null'
          enum:
            - CASHBACK
            - RELOAD_BONUS
            - SKU_TOPUP_BONUS
            - GATEWAY_BONUS
            - SIGNUP_BONUS
            - null
          description: Which lane accrued this grant.
        state:
          type:
            - string
            - 'null'
          enum:
            - LOCKED
            - RELEASED
            - CLAWED_BACK
            - EXPIRED
            - null
          description: Resulting grant state (same casing as promotional grant.state`).
        expires_at:
          type:
            - string
            - 'null'
          format: date-time
  securitySchemes:
    ApiKeyAuth:
      type: apiKey
      in: header
      name: x-api-key
      description: >-
        Partner API key (platform- or merchant-scoped). Contract key-enforces
        context.merchant_id.
    PosTerminalJWT:
      type: http
      scheme: bearer
      bearerFormat: JWT
      description: >-
        POS terminal JWT minted by /auth/token; carries integrationId +
        terminal/cashier claims (server-trusted).

````