October 9, 2026 · Muhammad Umar · More by Muhammad Umar
Stripe Connect: Unreject Accounts and Reject With a Balance
Stripe's Dahlia release lets platforms reverse their own account rejections and reject accounts that still carry a balance.
Stripe's July 29, 2026 Dahlia release (API version 2026-07-29.dahlia) shipped two changes to Connect account rejection that change what a platform's own risk and fraud workflow can do without opening a support ticket.
A self-serve way to undo a rejection
Previously, reversing a rejection on a connected account required contacting Stripe support directly — there was no API path back. The new Unreject an account endpoint changes that: a platform can now reverse a rejection it initiated itself. Stripe's documentation states that the unreject action "re-enables charges and payouts that were disabled by the rejection and reverts the account's application state." For a platform running its own fraud review, a false positive no longer has to mean a support queue and account downtime — it can mean a single API call.
The boundary: only rejections your platform started
The endpoint has one explicit limit worth designing around: it only reverses rejections your platform itself initiated. Stripe's changelog is specific that "you can't reverse Stripe-initiated rejections through this endpoint." If Stripe rejected an account — rather than your own rules engine — Unreject won't touch it. Any integration wiring this into a risk dashboard needs to track which rejections were self-initiated versus Stripe-initiated, since only the former are reversible this way.
Rejecting accounts that still carry a balance
The second change loosens a different constraint. Before this release, calling the Reject an account endpoint on a connected account with a non-zero balance returned an error — a platform had to wait for the balance to clear before it could reject the account, and payouts were always paused the moment rejection happened. The new payouts_action parameter removes both restrictions: it accepts pause (the default, matching prior behavior) or none, and the account can carry any balance at the time of rejection.
Together, these two changes mean rejection is no longer a one-way, balance-gated action. A platform can reject an account immediately when its own risk signals fire, without waiting on balance remediation, and if that rejection turns out to be a mistake, reverse it itself — as long as the platform made the original call rather than Stripe.
Neither change alters what triggers a rejection in the first place. Stripe's own risk and fraud detection for connected accounts is unchanged; what's different is how much of the aftermath a platform's own workflow can now handle on its own.