Skip to main content
Open in ClaudeOpen in ChatGPTllms-full.txt

Go-live checklist

Walked jointly with your integration contact once the sandbox test matrix is green. The order matters: production configuration is entered first, the live key is issued against it, and only then do you push real cases.

1. Sandbox complete​

  • Every row of the sandbox matrix passed, including the team-driven rows (assignment / visit; Mode A proof verification or Mode B mint)
  • POST /cases?dryRun=1 on a real production batch (from a copy of your live book, against the sandbox) — zero row errors, or every error understood and fixed at the source

2. Production configuration — entered again​

Nothing carries over from the sandbox. Give your integration contact the production values; ops enters them in the CRM before the live key is issued.

  • Production webhook URL: HTTPS, public IP, no query string, answers 2xx within 10 s, no redirects
  • Event subscriptions confirmed (default case.received, payment.collected, case.closed; case.assigned / visit.completed if you want them)
  • Mode A: production static UPI QR image / UPI ID / bank details — the account borrowers will actually pay into
  • Mode B: production mint URL and the exact Authorization header value we must send (verbatim, including your scheme prefix)
  • (Pull) production pull URL
  • (Optional) production IP allowlist (IPv4 / CIDR of the hosts that will call us)
  • RBI regulatory disclosure wording approved by your legal team (shown to the borrower on the agent's payment/ID screens); borrower receipts remain your responsibility — the platform does not issue PDF receipts
  • Technical contact confirmed — coordinates rotation and config changes. No automatic alerts are sent to you; monitoring is yours (§5)

3. Live key and first calls​

  • Live key (pk_<org>_live_<hex>) received; one-time secret stored in your secrets manager, never in a browser or client app
  • Base URL switched to https://gig.fluxusforge.in (test keys are rejected there with 401 UNAUTHORIZED)
  • GET /health with the live key → 200, env: "live", your lenderCode
  • POST /webhooks/test on production → delivered: true from your production receiver, signature verified with the production secret
  • Rotation-ready: your webhook receiver verifies against a list of secrets, so a future rotation (new secret signs webhooks immediately) does not stall your deliveries; you know rotation and revocation (≤60 s) go through your integration contact (key security)
  • Your client sends X-Fieldproof-Timestamp in unix milliseconds, signs the path without query string and percent-encoded, and backs off on 429 AUTH_LOCKED / 429 RATE_LIMITED using Retry-After — no tight retry loops (10 signature failures in 300 s lock the key for 900 s)

4. Receiver and payment logic​

  • Dedupe on eventId proven with a production replay (POST /webhooks/deliveries/{eventId}/replay) — reported as duplicate, not re-applied
  • Sequence handling: watermark keyed on (sourceLoanNumber, caseId) (or reset on case.received); events with sequence above the watermark are applied, gaps are normal (unsubscribed types still count) — never wait for a gap to fill; payment.collected is always booked (idempotent on eventId / reference), only case-state fields are gated
  • ping envelope (sourceLoanNumber: null, sequence: null) tolerated
  • Money applied from the absolute totalCollected / outstandingAfter in payment.collected, in whole INR rupees
  • Mode A: your team knows the amount in payment.collected is the operator-confirmed amount (it may differ from the partner's claim shown in GET /cases/{loan} visits[].amountCollected before verification)
  • Mode B: mint endpoint is idempotent (same live link for the same loan + amount), cancels a live link when a different amount is requested, refuses to mint when the loan has no outstanding, answers within 10 s; your gateway webhook handler (or poller) calls POST /cases/{loan}/payments/confirm with reference = gateway payment id, and retries a 5xx with the same reference
  • Mode B refund handling for confirm 409s is in place before the first live link is minted: DUPLICATE_CONFIRMATION → treat as success (already booked) · CASE_ALREADY_COLLECTED → the borrower paid money not owed → refund · AMOUNT_EXCEEDS_OUTSTANDING (over 101% of remaining) → refund / adjust · CASE_CLOSED (recalled / written off before payment) → refund
  • Recall tested on production (POST /cases/{loan}/recall) and your team knows a re-push after closure opens a new case with sequence back at 1

5. First production push​

  • Start with a small batch, ?dryRun=1 first, then commit with an Idempotency-Key; ops on standby on both sides
  • Then your full open book as one single batch with fullSnapshot: true — never chunked (any active case missing from a fullSnapshot batch is flagged for ops review); the hard cap is 20,000 rows per batch — if your open book is larger, agree an approach with your integration contact before go-live
  • Ongoing schedule agreed: fullSnapshot: true daily or weekly as a single batch, incremental updates without it; stay within 10 batches/hour (dry-runs and idempotent replays count)
  • Every row you re-send carries loan.dpd and loan.lateCharges — omitted values reset to 0 on re-push

6. Monitoring — yours, not ours​

The platform does not alert your organisation about exhausted deliveries, a suspended callback or a locked key. Before go-live, have in place:

  • A scheduled check of GET /webhooks/deliveries?status=exhausted (and status=pending / in_flight ageing) — replay exhausted events within 30 days with POST /webhooks/deliveries/{eventId}/replay
  • A scheduled GET /health from your production host with the live key
  • A periodic reconcile: GET /cases/updates (poll feed) or GET /cases/{loan} against your own records for anything a webhook could have missed (7 attempts over ≈31 h, then exhausted; 20 consecutive failures suspend your callback with a probe every 15 min)
  • X-Request-Id logged on every API response so [email protected] can trace an issue with you
  • If your firewall needs Fieldproof's egress IPs for webhook / pull / mint calls, you have asked [email protected] — none are published

After go-live (first 24 h)​

  • Watch your delivery log and your own webhook processing for anomalies; there is no automatic notification to you on delivery failure — check the log yourself.
  • Confirm the first real payment.collected reconciles against your bank / gateway (reconciliation).