Combined payments, reconciliation and rollout
If a payment is still processing The resident has already completed provider authorization. Do not ask them to pay again. Gather the property, resident, bundle, PaymentIntent/charge, and approximate...
Last updated
If a payment is still processing
The resident has already completed provider authorization. Do not ask them to pay again. Gather the property, resident, bundle, PaymentIntent/charge, and approximate time, then review:
- bundle and component status;
- invoice allocations or amenity/event settlement;
- Trigger settlement and recovery runs;
- journal entries and accounting audits;
- receipt and fulfillment claims.
The recovery sweep runs every five minutes. Captured or provider-ambiguous
bundles unresolved for 30 minutes should create an accounting escalation linked
to /accounting.
A combined payment refunded outside URBI now raises an alert of its own rather than waiting to be noticed. Treat it as work for a person: decide which component the refund belongs to and refund that component through its normal workflow. See Combined payments, accounting and refunds.
Safe rollout
Deploy in this order: migrations, recovery-capable Trigger tasks, Edge Functions, resident app, then enable the runtime flag for a controlled accounting-enabled property. Never enable the charge function before settlement and recovery are deployed.
At 24 hours, reconcile every capture. At seven days, review retry, expiry, refund, fee, wallet, support, and unchanged-payment metrics before expanding.
Escalation packet
Include property ID, payer user and billing account IDs, bundle ID, PaymentIntent and charge IDs, component IDs/types, expected/observed cents, JE and audit IDs, and relevant webhook/Trigger run links. Do not include card numbers, client secrets, access tokens, or raw provider payloads.