RevParPro · payment acceptance · review only
Provider-backed test-mode acceptance of base setup, the first charge, add-on checkout, failure, provider recovery, refund, cancellation, portal access, duplicate events, and responsive customer state.
Do not call the approved hotel-direct model accepted.
Today’s shared-payer model can activate one base hotel and bill additional monitored hotels on separate subscriptions under the same Stripe customer. It cannot represent three independent hotel payers or a corporate payer. A recovered Hotel B invoice also failed to restore the terminally canceled RPP item.
Zero-dollar card setup, signed activation, a sandbox-only first-issue charge, authenticated $9 add-on checkout, full refund, cancellation isolation, portal creation, and duplicate-event idempotency were provider-proved.E3,E4
| Check | Result | Evidence-backed finding |
|---|---|---|
| Zero-dollar base setup | PASS | Hosted Checkout completed in setup mode with no payment required; signed setup activation made the account and included hotel active.E3,E4 |
| First base charge | PASS | The service-only first-issue path created and verified the $15 standard subscription after one explicit sandbox issue key.E3,E4 |
| Authenticated add-on checkout | PASS | Two signed-in calls reached Stripe Checkout, each at $9 monthly, and activated one hotel-bound add-on item.E3,E4 |
| Hotel C refund + cancel | PASS | The $9 charge was fully refunded and the add-on subscription, item, and hotel were canceled while Hotel A and Hotel B remained active.E3,E4,E5 |
| Hotel B failure isolation | PASS | Provider dunning canceled Hotel B only. Hotel A, the base membership, and the account remained active.E3,E4,E5 |
| Hotel B recovery propagation | FAIL | The saved valid test card paid the failed invoice, but the signed invoice.paid receipt was ignored as terminal; Hotel B remained canceled.E3,E4,E5 |
| Billing portal + returns | PASS | An authenticated test-mode portal session was created with the Account return route.E3 |
| Duplicate events | PASS | Exact signed event replay returned the replay path and did not create a second receipt or mutation.E4 |
| Desktop + mobile state | PASS | Five lifecycle checkpoints were verified at 1440px and 390px with all expected labels present and zero console errors in the final failure/recovery states.E5 |
| 3 independent hotel payers + corporate payer | FAIL | Provider identity exists only on the account-level membership; hotels have no billing identity columns and corporate service is not an allowed item kind.E1,E4 |
| Commercial copy versus renewals | WARNING | The base subscription renewed for $15 on the provider clock with zero monthly delivery events, while Account copy says the charge follows delivery and never the calendar.E3,E4,E5,E6 |
Hosted setup completed at $0. RPP activated the base membership from a signed provider event.
The sandbox-only first-issue action created the $15 base subscription and verified the charge.
Authenticated add-on Checkout created two $9 monthly subscriptions under the shared customer.
Full refund succeeded, then cancellation propagated only to Hotel C.
Dunning produced eight processed failures, one out-of-order ignored failure, then terminal cancellation.
The invoice became paid, but the application’s terminal reducer refused restoration.
| Transition | Provider | Application | Database | Visible state |
|---|---|---|---|---|
| Base activation | Setup succeeded, $0 due | Account active | Saved-method and activation receipt | Active, $15/month, 1 hotel |
| Add-ons | 2 paid $9 subscriptions | 3 hotels active | 2 active hotel-bound items | 3 active |
| Hotel C refund/cancel | Refunded, subscription canceled | Only Hotel C canceled | Refund action succeeded | 2 active, refund shown |
| Hotel B failure | Failed dunning, subscription canceled | Hotel A stayed active | Failure + delete receipts processed | 1 active, 2 canceled |
| Hotel B provider recovery | Failed invoice paid | Hotel B stayed canceled | invoice.paid ignored as terminal | Paid charge shown, hotel still canceled |
Cross-hotel isolation passed for failure and cancellation. The base account and Hotel A remained active throughout both add-on terminal paths. Isolation does not equal independent billing identity: all three provider subscriptions still belong to one shared Stripe customer.E3,E4
There is one provider customer on rpp_memberships. Neither accounts nor account hotels have billing identity fields. Separate payment methods, invoices, tax identity, contacts, and portal ownership per hotel cannot be represented.
Membership items permit only base and monitored_hotel_addon. A company-level service has no product/item kind, payer, invoice stream, or visible account row.
Once dunning cancels an add-on, provider recovery does not restore it. The webhook reducer ignores the paid event as terminal, and authenticated add-on checkout will not restart a hotel in canceled state.
The first charge is delivery-gated, but the resulting Stripe subscription renews on its calendar. The fixture recorded a $15 renewal while the account had zero monthly delivery events. Current customer copy overpromises delivery gating.
Both add-on success and cancel URLs point to /app/compsets, even though the paid customer front door is Reports and Account.
The single Hotel B renewal produced nine failure receipts and repeated visible payment-failure entries before cancellation. The state is honest, but the history is noisy and hard to reconcile.
| Capability | Current implementation | Approved hotel-direct target | Gap |
|---|---|---|---|
| Management company | One RPP account | One consolidated company view | PRESENT |
| Hotel payer | No hotel billing identity | One billing profile per hotel | MISSING |
| Provider customer | One on the account membership | 3 hotel customers + 1 corporate customer | MISSING |
| Hotel lifecycle | Separate add-on subscription and item | Independent payer, invoice, failure, recovery, refund, cancel | PARTIAL |
| Corporate service | No item kind or identity | Visible, separately billed company service | MISSING |
| Consolidated visibility | One Account view lists all hotels | Company view rolls up all billing identities | PARTIAL |
| Failure isolation | Add-on failure did not pause the base | One hotel’s failure cannot affect another | MECHANICS PASS |
| Recovery | Terminal item cannot reopen | Recovered hotel resumes without manual database repair | FAIL |
The test used current origin/main code at commit 43ca9749. The deployed production functions were inspected read-only and downloaded for route reconciliation. Because the deployed project correctly holds live Stripe secrets, provider writes were run through the same edge handlers locally with test-mode keys and a loopback-only port option. The production schema, deployed customer-account read model, and production desktop/mobile UI were used for RPP state evidence.E1,E2,E4,E5
| Boundary | What happened |
|---|---|
| Provider safety | Stripe test mode only. No live card, live Checkout Session, live charge, prospect, or real customer was used. |
| Fixture | One synthetic management company, three synthetic hotel rows, one synthetic authenticated owner, and one target-only corporate service row in this matrix. |
| Report delivery | The first base charge used an explicit sandbox issue identity. No production report-delivery rule was bypassed for a real customer. |
| Sanitization | No secret, raw provider identifier, authentication token, real customer record, or screenshot containing the synthetic login alias is published here. |
| Changes | No product code, billing policy, production function, migration, or customer-facing behavior was changed. |
origin/main commit 43ca9749; paid-checkout, stripe-webhook, customer-account, membership-billing, migration 1060, and customer Account UI inspected 2026-09-16 Central.RevParPro Pricing.md, especially “How money moves” and “The guarantee,” plus the project Handoff contract dated 2026-09-16.npm run test:paid-customer-core passed all six groups; the billing module’s 26 Deno tests passed independently.