We operate a self-serve pay-as-you-go service (car wash) where customers authorize a maximum hold at session start, use the service, and are charged only for actual usage at session end. The final charge is almost always less than the original hold. (similar to gas stations)
Example flow:
- Customer authorizes a $10.00 hold
- Session runs for 3 minutes and 30 seconds
- Actual charge is $3.50
- We call UpdatePayment to set amount_money to $3.50, then CompletePayment
The Problem
After calling UpdatePayment with a reduced amount followed immediately by CompletePayment, the customer’s banking app continues to show the original $10.00 hold as a pending transaction. The correct $3.50 amount only appears once the transaction fully settles (1–3 business days later).
This creates a significant and recurring customer support burden — customers see $10.00 pending and believe they were overcharged. The final charge is always correct, but the pending display causes confusion and distrust.
Root Cause (as we understand it)
When UpdatePayment reduces amount_money, Square updates its internal record but does not send an authorization adjustment to the card network. As a result, approved_money remains at the original hold amount. The issuing bank’s app reflects approved_money, not amount_money, so the customer never sees the updated amount during the pending period.
This is confirmed by the Square documentation:
“This value [approved_money] may change if Square chooses to obtain reauthorization as part of a call to UpdatePayment.”
Square only triggers reauthorization at its own discretion — and in practice, does not do so for amount reductions.
There is no developer-controlled parameter to request or force an authorization adjustment.
We also confirmed this via the Square Developer Forum thread “Authorized amount is changed and then completed: no changes in bank account” ( Authorized amount is changed and then completed: no changes in bank account ), where Square support confirmed this is expected behavior.
Feature Request
We are requesting one or both of the following:
Option A — A flag on UpdatePayment to request an authorization adjustment
Add an optional boolean parameter such as request_reauthorization: true or send_authorization_adjustment: true to the UpdatePayment request body. When set, Square would attempt to send an authorization adjustment to the card network for the updated amount — for both increases and decreases — and update approved_money accordingly. The call could return a field indicating whether the adjustment was sent successfully, without failing the overall update if the network adjustment is not supported by a particular card type.
Option B — A standalone AdjustAuthorization endpoint
A dedicated endpoint separate from UpdatePayment that explicitly sends an authorization adjustment to the card network. This would give developers explicit control over when to attempt a network-level adjustment, decoupled from the amount update and capture flow.
Why This Matters
The UpdatePayment + CompletePayment pattern for delayed capture is the documented and recommended Square approach for pay-as-you-go billing. The inability to update the customer-visible pending amount is a significant UX gap for any business that:
- Authorizes a maximum hold upfront
- Bills only for actual usage
- Has customers who actively monitor their banking apps
Industries affected include car washes, EV charging stations, laundromats, parking, hotel incidentals, fuel, and any metered self-serve service. This is not an edge case — it is the primary use pattern for delayed capture in pay-as-you-go contexts.
Summary
UpdatePayment reducing amount_money does not update approved_money or notify the card network. Customers see the original hold amount in their banking apps until full settlement, which undermines trust in pay-as-you-go businesses using Square’s delayed capture flow. A developer-controlled mechanism to request a card network authorization adjustment on amount reductions would directly solve this.