1. Start with three separate questions
The review queue contains completed or to-be-captured payments. Payments entering review are typically already successfully processed unless the integration captures later.[2] Therefore, ask separately: what did the reviewer decide, what happened to the payment, and should the merchant fulfill the order?
Review availability depends on a plan supporting the feature. Manual review covers most Radar-supported payment methods, but not ACH or SEPA direct debit payments. For unsupported review methods, Stripe recommends allow or block rules and checking their test results.[2] Editorial recommendation: verify eligibility before designing a manual-review route; do not promise customers that every payment can enter it.
Editorial recommendation: maintain separate review, payment and fulfillment records. A closed review is evidence about the review workflow, not a universal instruction to ship, activate access or record a refund.
2. Read each action literally
Approve closes the review without changing the payment; an approved payment can still be refunded and optionally reported as fraudulent.[2] Approval is consequently not a receipt for a new collection action. Editorial recommendation: record the decision and its rationale without overwriting the payment record.
Refund returns the payment without reporting it to Stripe as fraudulent. A completed refund is permanent and cannot be undone; collecting again requires a new payment.[2] Refund and report fraud both refunds and reports fraud, adding the associated card fingerprint and customer email to block lists.[2] Editorial recommendation: distinguish a commercial refund from a fraud conclusion before selecting the combined action.
For uncaptured payments, Cancel replaces Refund: cancellation releases the authorization without creating a Refund object.[3] Approval and capture remain separate; approval does not automatically capture, and capture can occur before or after approval.[2][3] Editorial recommendation: confirm the payment's actual state before interpreting a button or looking for a refund record.
3. Assign work without mistaking ownership for a lock
Reviewers can assign or remove themselves, see colleagues' assignments and filter their own or unassigned reviews. They cannot change assignments for other team members. However, they can act on a review assigned to someone else or assign it to themselves; the timeline records assignment changes and other actions.[2]
Editorial recommendation: use one named reviewer for the risk decision, a payment operator for refund or capture verification, and an order owner for fulfillment. These are suggested responsibilities, not additional Stripe permission rules. Before acting on a colleague's item, check its timeline and coordinate the handoff. Assignment alone does not prevent conflicting actions.
Editorial recommendation: handoffs should include review and payment identifiers, the observed payment state, evidence considered, the chosen action and the next owner. Separate risk approval from permission to release goods.
4. Route events by meaning, not just closure
review.opened means a transaction entered the queue and a Review object was generated. review.closed means that object closed and supplies a reason.[2] A customer dispute against a payment still in review automatically closes that review.[2] Closure alone therefore cannot mean approval.
Stripe's uncaptured-payment example listens for review.closed and captures only when reason is approved.[3] Editorial routing recommendation: send opened reviews to investigation; approved closures to payment-state verification; refund-related closures to refund verification; dispute-driven closures to the dispute owner. Send other or unclear reasons to exception handling rather than guessing. These are business routes, not a complete enumeration of API reason values.
Editorial recommendation: invoke an approval-triggered capture path only for the intended uncaptured-payment workflow. Never route every closed review to capture or fulfillment. A dispute-driven closure should trigger a handoff, not a fabricated reviewer approval.
5. Define completion independently
Editorial recommendation: review work is complete when the closure reason, evidence and owner are recorded. Payment work is complete when the intended action's outcome has been checked: unchanged payment after approval, capture outcome where applicable, refund completion, or authorization cancellation. Fulfillment work is complete only after the order owner records whether to release, hold or stop delivery under merchant policy.
Hypothetical example: a paid physical-goods order is approved after its shipping context is checked. Approval leaves its payment unchanged.[2] The suggested next step is an explicit fulfillment decision, not another charge. In contrast, an approved uncaptured order still needs a separate capture action.[3]
Hypothetical example: a dispute arrives while two colleagues investigate. Stripe automatically closes the review.[2] The suggested completion criterion is a documented transfer to dispute handling and a separate delivery decision—not an empty review queue.
6. Prevent semantic mistakes
Editorial checklist: verify captured versus uncaptured status; distinguish refund from fraud reporting; coordinate assignments; inspect closure reason; confirm payment outcome; document fulfillment separately. Mistakes can cause unnecessary new payments, misleading refund records or unintended block-list additions. Do not treat queue clearance as the measure of successful handling.
Sources and dates
Official Stripe documentation in English. No publication or update date is stated; retrieved and checked on 2026-09-21. The retrieval date is not a source publication date. This is editorial research, not a PayIn feature claim, account eligibility check, or legal advice.
- [2] Review payments · Checked 2026-09-21; source date not stated.
- [3] Review uncaptured payments · Checked 2026-09-21; source date not stated.