Apple Pay pre-auth: how to not show hold amount (gas-station style) for usage-based rentals?

Question

Created 2w

Replies 3

Boosts 0

Participants 2

We’re building a usage-based rental flow. The final charge is only known after the session ends (like gas pumps). We want the same Apple Pay UX that gas stations like at a gas station has: the user does not see a pre-authorization amount up front; they only see “approved” and later the final posted amount on the statement.

What we observe (gas stations / desired UX)

When paying at gas station with Apple Pay (card-present), the user confirms their card (double-tap) but no pre-auth amount is shown in Wallet/notification UI.

The small notification is from the bank (not the merchant) and shows only bank + merchant name, no total.

After fueling ends, the final amount appears on the statement from the merchant.

What happens in our flow (current behavior)

Platform: Apple Pay via Stripe (Apple Pay on the Web with QR → mobile Safari Wallet sheet).

When a user confirms payment, the pre-authorization amount is shown immediately to the user (appears like a charge from the user’s perspective).

We want to avoid showing that amount, matching the pay-at-pump experience.

Answered by by_ptr in 861207022

The $1/0 preauth would only be used to save the card in your system. The actual charge would be made once the amount is finalized. If your bank allows it, you could do a sale here directly, no need to do preauth/capture.

I’d also suggest implementing future payments for declined charges. For example, if a charge fails on t, you could set up a flow that tries the same charge again on t+1.

Like I said, you've gotta be careful here, Credential on File has a lot of rules and regulations and stuff you need to consider. I would definitely recommend talking to your gateway/bank/service provider before moving forward.

Boost

Answer 1

by_ptr OP

2w

With card present environments, what's happening there is Apple Pay is sending the DPAN and cryptogram to the terminal, and terminal completes the charge.

However, in card not present environments, from a payment processing UX perspective, the user has to see the amount they are confirming for pre-authorization. Otherwise it could lead to fraud cases.

You could consider talking to your gateway or bank for Credential On File (COF) if you want to implement something similar to card present environments: You can save the card with a symbolic amount (or zero if the banks allow it) and then use the card you saved for the actual charge. But please beware that Credential On File brings its own set of rules and implementation requirements.

0

Answer 2

jzl1107 OP

2w

Thanks for the explanation, that helps. One concern I still have is if we only pre-auth for $0 or $1 to save the card, what happens when we go to capture the final amount later and the customer doesn’t have enough available credit. My understanding is the payment would just fail at that point. Is there any way to reduce that risk in a card not present flow, or is the only option to re-prompt the customer for payment if the charge is declined?

Thank you for you help! Truly!

0

Answer 3

by_ptr OP

1w

Accepted Answer

The $1/0 preauth would only be used to save the card in your system. The actual charge would be made once the amount is finalized. If your bank allows it, you could do a sale here directly, no need to do preauth/capture.

I’d also suggest implementing future payments for declined charges. For example, if a charge fails on t, you could set up a flow that tries the same charge again on t+1.

Like I said, you've gotta be careful here, Credential on File has a lot of rules and regulations and stuff you need to consider. I would definitely recommend talking to your gateway/bank/service provider before moving forward.

1