auto-data-snapshot: 2026-09-24T07:06:26 (1 data files) — docs/GO-LIVE.md

fc341d1b06b25f6027d00f64a1d54e90cd025445 · 2026-09-24 07:06:54 -0700 · auto-commit-fleet

Files touched

M docs/GO-LIVE.md

Diff

commit fc341d1b06b25f6027d00f64a1d54e90cd025445
Author: auto-commit-fleet <steve@designerwallcoverings.com>
Date:   Thu Sep 24 07:06:54 2026 -0700

    auto-data-snapshot: 2026-09-24T07:06:26 (1 data files) — docs/GO-LIVE.md
---
 docs/GO-LIVE.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/docs/GO-LIVE.md b/docs/GO-LIVE.md
index 90b745c..de09722 100644
--- a/docs/GO-LIVE.md
+++ b/docs/GO-LIVE.md
@@ -67,7 +67,8 @@ These closed in the /yoloforever cycles; they need no creds and are already live
 1. **Webhook signature encoding** — adapters compare hex; if the provider signs base64, set `Buffer.from(sig,'base64')` explicitly once the real delivery is observable.
 2. **Provider-honored idempotency key (#6 live half)** — pass the provider's real idempotency header/field (ONVO `Idempotency-Key`-style; Tilopay per its live account) on `createCharge` **and** on the SINPE `payout` transfer, so a retry after a timeout can't double-charge a traveler or double-pay a host. The local pre-charge-row half is already in; this is the provider-side guarantee.
 3. **Confirm each provider's REAL decline status strings** against `mapStatus()` in `lib/payments/tilopay.js`/`onvo.js` — the maps are built from documented vocabularies (Stripe-like for ONVO), not the live account; a status string the map doesn't recognize safely defaults to `'processing'` (not `'failed'`), so an unmapped real-world decline string would silently NOT fail closed. Watch the `raw` field on any `processing` row that never resolves.
-4. **Verify with a $1 real charge + refund** before opening bookings.
+4. **⚠ ONVO refund detection (BLOCKER before `PAYMENT_PROVIDER=onvo`)** — the webhook decides "refunded" from `getCharge().status`. `onvo.js` `STATUS_MAP` now maps `refunded`/`reversed`→`'refunded'` (cycle-29 fix; Tilopay already mapped `reversed`), BUT ONVO's EXACT post-refund vocabulary is UNVERIFIED. If ONVO is Stripe-like, the payment-intent status STAYS `'succeeded'` after a refund (refund is a separate object / a `charge.refunded` flag), in which case the status-map key never fires and `getCharge` must instead inspect the refund object. Verify against ONVO's real API + the $1 refund test below and adjust `getCharge`/`STATUS_MAP` accordingly — do NOT flip ONVO live until a real refund is observed flipping the booking to `refunded`. (Tilopay's `reversed` path is the verified reference.)
+5. **Verify with a $1 real charge + refund** before opening bookings — confirm the refund flips both `payments.status` and `bookings.status` to `refunded` for the ACTIVE provider.
 
 ## 6. Verify money math
 `total = platform_fee + host_payout` (10% platform fee; `fees` is display-only). Enforced by DB CHECK `bookings_total_reconciles` + `test/money.test.js`. Booking amounts are capped: stays > `MAX_BOOKING_NIGHTS` (default 365) and any amount that would overflow the INTEGER (int4) money columns are rejected with a 400 at `POST /bookings` (cycle-14 guards).

← 0b0f3fc cycle 28 docs: YOLO_NOTES ledger — admin CSRF fix + gate-cou · back to Costa Rica · costa-rica: fix payment-webhook refund path — ONVO status ma 762091f →