3DS-authenticated recovery for failed initial Vrbo payments - avoid the new-card retry loop

We are requesting an OwnerRez-managed recovery flow that lets a guest complete the outstanding initial booking payment with successful 3DS authentication after an initial Vrbo charge fails or requires authentication.

Specific scope

OwnerRez already supports 3DS in certain checkout flows and already sends failed-payment emails. The missing capability is completing the actual payment through the recovery route described below.

Current limitation confirmed by OwnerRez support

1. An initial Vrbo payment is submitted off-session.

2. If a host’s Stripe Radar policy rejects that unauthenticated payment, the guest receives “First payment FAILED.”

3. The email link routes this booking to the new-card form.

4. That form saves the card and charges the amount due off-session, without 3DS on the actual payment.

5. The replacement charge encounters the same blocking condition, leaving the guest unable to complete payment through that route.

Requested behavior

Provide an opt-in recovery flow that:

• Lets the guest pay the full outstanding amount while actively on the payment page.

• Supports successful frictionless or challenge-based 3DS on that payment.

• Supports a host policy requiring successful authentication before accepting the initial payment.

• Updates the existing booking, outstanding balance, and subsequent payment schedule correctly, without duplicate charges.

• Preserves existing security-deposit holds and unattended renewals; those renewals must not require fresh guest participation because of this feature.

Authenticating only a card-save SetupIntent or a separate nominal verification payment does not meet the requested payment-authentication requirement.

Supporting metadata

Before Stripe confirmation, provide stable booking-source and transaction-purpose metadata distinguishing initial channel payments, recovery attempts, scheduled balances, staff charges, deposit holds/renewals, and deposit-capture fallback payments.

Support confirmed that these different ORPAY transactions currently cannot be distinguished reliably using their existing metadata and descriptions. The additional identifiers would allow selective Radar policies without blocking unrelated payment operations.

Relationship to existing requests

We reviewed these related topics, but they are not the same:

• Vrbo declined-card message trigger: addresses sending the notification. This request addresses the payment flow reached from it.

• Stripe metadata for chargeback protection: requests name-comparison data. Our supporting metadata identifies the transaction’s source and purpose.

• Stripe mandate.updated webhook: addresses revoked authorization for future card use. Our request addresses authentication of an outstanding initial payment.

• More Stripe payment options: addresses additional payment methods. This request concerns the existing card-payment recovery workflow.

If an existing request already covers this complete recovery flow, please link it so we can contribute there. Otherwise, please evaluate this specific recovery capability and its supporting transaction identifiers.