AutoCore Payment States, Checkout, and Refunds
Documents payment order, attempt, expiry, settlement, refund, and dispute states.
Payment state is authoritative in the order and attempt records. Hosted approval is not settlement: the server must receive a verified provider result before marking an attempt succeeded and releasing fulfilment behavior.
Release candidate source
This article reflects the audited AutoCore source revision 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60 and immutable release-candidate tag v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f. Configuration and external provider behavior remain deployment-dependent.
Source boundary
| Control | Source-verified behavior |
|---|---|
| Order | Draft, pending_payment, processing, paid, fulfilment_pending, completed, failed, cancelled, expired, refund, and dispute states are explicit. |
| Attempt | Created, requires_action, pending, authorized, succeeded, failed, cancelled, expired, refund, and dispute states are provider-reconciled. |
| Refund | Idempotent full/partial refund requests check positive integer amounts, successful attempts, remaining refundable value, and provider capability. |
| Dispute | A dispute freezes relevant wallet behavior and requires operational review; it is not silently treated as a refund. |
Operational controls
Use the smallest verified control for the task. Keep provider, host, legal, and operator responsibilities separate from application behavior. When a control is not implemented or not verified, leave it disabled or mark it as a limitation.
Verification
Verify the route, relevant API or configuration state, negative path, audit/evidence result, and public effect before closing the task. Record unknown or configuration-dependent behavior as a limitation.