How money flows

Every rupee is collected directly on YOUR payment rails. Fieldproof runs the field operation and keeps the authoritative collection record — but never holds, routes, or touches your borrowers' money. There is no Fieldproof settlement account, no payout cycle, and nothing to reconcile with us financially: you reconcile our events against your own bank or gateway.

Two consequences follow:

• Cash is never accepted in the field on external-organisation cases. The partner app removes the option entirely, and payments/confirm rejects mode: "cash" with 422. (A cash payment our collection team records for you — below — is reported as mode: "other".)
• A payment is announced only after it is booked — proof-verified by our operations team (Mode A) or confirmed by you (Mode B). We never emit payment.collected for an unverified claim.

The two modes

	Mode A — your static QR / bank (default)	Mode B — your gateway's links
Money lands in	Your bank account, directly	Your gateway / bank, directly
Borrower pays via	Your fixed UPI QR, UPI ID or bank details, shown in the partner app	A payment link minted by your gateway when the partner requests it during the visit
Confirmation	Partner uploads proof → Fieldproof ops verifies (OCR-assisted UTR / amount) → event	You call payments/confirm when your gateway captures → event
Amount booked	The operator-confirmed amount (may correct the partner's claim)	The amount you confirm
reference on the event	UTR where extracted, otherwise null	Your gateway's payment id — the same reference you sent
You build	Nothing payment-specific	A mint-link endpoint we call + one confirm call you make
Confirmation latency	After operator verification	Immediate on your confirm call
Failure mode	A rejected proof emits nothing	A failed mint shows "link unavailable" — no fallback

Details: Mode A · Mode B · Reconciliation

In either mode, Fieldproof's collection team can occasionally book a payment taken outside the partner flow, and you get the same events:

• Record payment — payment.collected with the mode they recorded (other for cash, IMPS or any mode outside the event's list) and the UTR / reference they entered (or null). If it completes the case, case.closed follows.
• Direct close — payment.collected with mode: "other" and reference: null only if they recorded an amount, then case.closed.

The case.closed always comes after the payment (higher sequence), with status: "collected" and reason full_settlement (balance cleared) or closed_by_operations (closed with a balance left, or no amount recorded) (event reference).

The mode is chosen at onboarding and configured per environment by Fieldproof ops — sandbox and production artefacts (QR / bank details, or mint URL and Authorization value) are registered separately. payments/confirm is available only to Mode B organisations; anyone else gets 403 PAYMENT_MODE_MISMATCH.

What the borrower sees, and receipts

The RBI regulatory disclosure text you provide is shown to the borrower on the partner's payment and identification screens. The platform does not issue PDF receipts on your behalf — you remain responsible for borrower receipts from your own system, which is natural given the money is already in your account.

The invariant either way: the money is always on your rails, and a payment.collected event is only ever emitted once the payment is booked — never for an unverified claim. Book it as the transaction of record (Updating your LMS) and use your bank or gateway statement as the audit pair.