Clarification Required for No-Show Fee Implementation and Authorization Handling

Questions
1

Hello,

We are currently evaluating the implementation of a no-show fee feature and require some information regarding authorization handling.

As background, we already have an active integration with your web PSP, and we are assessing whether the existing integration can support this use case or if additional development will be required.

Could you please provide clarification on the following points:

  • How long can an authorization remain uncaptured?
  • Are there differences between Visa, Mastercard, Amex, or other card schemes?
  • Are there differences between Card Present (CP) and Card Not Present (CNP) transactions?
  • Can the authorization validity period be extended?
  • What happens after an authorization expires?
  • Is re-authorization required after expiration?
  • Is partial capture supported?
  • Is multiple capture supported?

In addition, we would appreciate answers to the following:

  • Is official documentation available that covers these topics?
  • Who can officially confirm the information provided (e.g., product management, certification team, scheme compliance team, etc.)?

Thank you in advance for your support.

Best regards,
Jakob

4

For a no-show fee, I’d advise to not rely on holding an authorization. Square’s auth windows are short and can’t be extended. A more stable method is to store the card on file at booking, then charge it when the no-show happens, which shouldn’t require changes to your existing payment path.

Point by point:

Auth lifetime — autocomplete: false on CreatePayment authorizes without capturing. Defaults are 36 hours card-present and 7 days card-not-present. On the Web Payments SDK you’re in the 7-day bucket. (Delayed Capture)

Card schemes — no differences on the Square API surface; same thresholds for Visa, Mastercard, Amex, etc.

CP vs CNP — yes, that’s the 36h vs 7-day split above.

Extending — not possible. delay_duration can only shorten the window; there’s no extend-auth endpoint. You can adjust the amount via UpdatePayment if capabilities include EDIT_AMOUNT_UP/EDIT_AMOUNT_DOWN, but issuer approval isn’t guaranteed, and in SCA/3DS markets increasing much past the authenticated amount gets declined.

After expiry — Square acts on delay_action: CANCEL (default) voids it, or COMPLETE captures it (only allowed if you didn’t pass an order_id). delayed_until tells you when. Note that cancelling leaves the associated Order OPEN — you update that yourself.

Re-auth — required, and note that an expired or cancelled auth can’t be revived, including by Square support. Your only recovery is a new charge against a saved card, which is why card-on-file matters here. (Charge and store cards)

Partial capture — CompletePayment captures the full authorized amount. To capture less, reduce the auth first with UpdatePayment, or refund down after capture.

Multiple capture — no. One authorization maps to exactly one capture. Use separate authorizations if you need multiple amounts.

Docs — the Delayed Capture guide, Payments API reference, Cards API, and SCA overview cover most of this. The scheme-parity and SCA-overcapture notes above come from field experience rather than published docs.

One last thing: no-show fees are a common chargeback trigger, so disclose them clearly in your booking terms and use itemized orders plus a descriptive payment.note — both materially help dispute outcomes.