Mode A — your static QR / bank details

The default mode, and the one that needs no code from you: the partner shows the borrower your payment details, the borrower pays your account, and Fieldproof's operations team verifies the partner's proof before anything is booked or emitted.

You provide (once per environment, at onboarding)

• Your static UPI QR image and/or UPI ID
• Bank account details (account name, number, IFSC) for borrowers who transfer instead of scanning

You build

• Nothing payment-specific — you learn about payments the same way you learn about everything else: webhooks or the poll feed

We provide

• Your QR / UPI ID / bank block rendered in the partner app at the borrower's door
• Proof upload from the partner and OCR-assisted UTR / amount reading
• Operator verification before anything is booked
• The ledger record and the payment.collected event after verification

Mode A artefacts are configured by Fieldproof ops in the CRM Integrations tab. Sandbox and production are separate: at go-live you supply the production QR / UPI ID / bank details again — nothing carries over from sandbox.

The flow

1. The partner opens the payment step and shows the borrower your QR, UPI ID or bank details in the app. Cash is not offered — the app removes it for external-organisation cases.
2. The borrower pays. Money lands in your account immediately; Fieldproof never sees or touches it.
3. The partner records the collection — amount, payment mode (usually upi) — and uploads the payment proof. Nothing is emitted yet. The case holds the partner's claim pending verification.
4. Fieldproof's operations team verifies the proof, with OCR reading the UTR and amount to assist the operator.
5. On verification the ledger row is written and payment.collected fires, carrying the operator-confirmed amount — which may differ from what the partner claimed. Trust the event. If the verified amount clears the outstanding, case.closed follows with status: "collected", reason: "full_settlement".
6. A rejected proof emits nothing — no payment.collected, no correction event. From your side a rejected claim never existed.

payment.collected payload after a Mode A verification

{
  "sourceLoanNumber": "LN-2026-0001",
  "caseId": "CC-2026-2388ED42",
  "amount": 3000,
  "mode": "upi",
  "reference": "UTR2026081812345",
  "totalCollected": 3000,
  "outstandingAfter": 9500,
  "collectedAt": "2026-08-18T09:30:12.000Z"
}

• amount is the incremental verified figure in whole INR rupees; totalCollected and outstandingAfter are absolute for the case.
• mode is the mode the partner recorded — usually upi.
• reference is the UTR where it could be extracted, otherwise null. Do not make your booking depend on it being present.

:::warning Before verification, GET /cases shows an unverified claim GET /api/v1/partner/cases/{sourceLoanNumber} lists the last 20 visits with amountCollected, paymentMode and paymentReference. Until operations verify a proof, that visit's amountCollected is the partner's unverified claim. Never book money into your ledger from the case snapshot — book only from payment.collected, which exists only for verified money. :::

Reconciling on your side

Pair each payment.collected with the matching credit in your bank statement — by amount and by reference (the UTR) when present, by amount and collectedAt when not. Because verification is operator-gated, treat the event as your bookkeeping truth and the bank statement as its audit pair; a credit that never produces an event, or an event you cannot pair, is a support escalation to [email protected] with the eventId — not something to resolve by guessing. Full detail in Reconciliation.

:::tip Sandbox The sandbox has no simulated field agents, so nobody uploads proofs by themselves. Ask [email protected] to run a Mode A verification against one of your sandbox cases — you will see the payment.collected (and, on full clearance, case.closed) land at your sandbox webhook and in GET /cases/updates, exactly as in production. :::

Want confirmations without an operator in the loop? That is Mode B — links minted on your own gateway, confirmed by you.