{"id":19182,"plugin_id":"plugins_6a9319929b74819193f3f276f98627c4","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:15:20.926Z","digest":"55f2f204a4484cd9bdf88c4ce0c1189994b08765b46135f6563d00836cacb7f5","against":null,"payload":{"description":"Use only for payment/rail authorization, capture, refund, webhook, and ambiguity. Do not use for non-financial effects.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":264},{"relative_path":"evals.json","size_in_bytes":9503},{"relative_path":"references/authorization-adjustments.md","size_in_bytes":2334},{"relative_path":"references/disputes-and-evidence.md","size_in_bytes":4126},{"relative_path":"references/partial-capture-and-refund-accounting.md","size_in_bytes":3898},{"relative_path":"references/payment-machine.md","size_in_bytes":802},{"relative_path":"skill.json","size_in_bytes":3977}],"name":"go-payment-lifecycles","skill_md_contents":"---\nname: go-payment-lifecycles\ndescription: \"Use only for payment/rail authorization, capture, refund, webhook, and ambiguity. Do not use for non-financial effects.\"\nlicense: Apache-2.0\ncompatibility: \"Go 1.24 or newer; provider, rail, and scheme state semantics are version- and region-specific.\"\n---\n\n# Go payment lifecycles\n\nModel provider evidence as events and local payment state as a constrained projection. A network result is not automatically a financial result.\n\n## Define the machine\n\nList states, legal commands, provider requests, provider evidence, terminality, amount constraints, expiry, and late-event behavior. Keep authorization, capture, refund, reversal, dispute, and settlement distinct even if the UI says “paid.”\n\n## Handle ambiguous outcomes\n\nA timeout or lost response after request transmission can mean success, failure, or still processing. Persist the attempt and stable provider identity, replay only under the provider's idempotency contract, identify what evidence is authoritative for this provider or rail and whether its query can lag, and reconcile asynchronous evidence. Never create a new payment identity merely because the response was missing. If the deployed provider or rail contract is unavailable, stop at a conditional state machine; do not transfer Stripe-specific idempotency, expiry, or finality semantics to ACH or another rail.\n\n## Apply events safely\n\nVerify authenticity before parsing into trusted events. Deduplicate by provider event or operation identity, but make handlers tolerant of out-of-order evidence. Distinguish duplicate, stale, future/missing-predecessor, conflicting, and contract-invalid evidence. Persist future evidence such as refund success arriving before capture success and reevaluate it when prerequisites arrive; quarantine only contract-invalid or irreconcilably conflicting evidence. Apply transitions conditionally against current version/state.\n\n## Amount and terminality\n\nEnforce cumulative capture and refund limits with exact money. Partial capture/refund and multiple disputes can coexist. “Succeeded” may be locally terminal for fulfillment while chargebacks and settlement adjustments remain possible.\n\nFor multi-capture or partial-refund flows, allocate each amount-bearing operation to stable payment, capture, shipment or item, and provider identities. Fulfill only the durably captured allocation, never a payment-wide Boolean. Persist provider capability and final-capture semantics, serialize concurrent amount decisions, and reconcile aggregate fields to item-level evidence. Read [references/partial-capture-and-refund-accounting.md](references/partial-capture-and-refund-accounting.md); its Stripe rules remain Stripe-specific.\n\nRead [references/payment-machine.md](references/payment-machine.md) for transition and ambiguity rules.\n\nFor partial authorization, incremental authorization, capture, void, or authorization-reversal changes, read [references/authorization-adjustments.md](references/authorization-adjustments.md). Preserve requested, approved, capturable, captured, and released amounts separately; provider-specific remainder-release behavior is not a portable payment rule.\n\nFor card disputes, chargebacks, evidence, or representment, read [references/disputes-and-evidence.md](references/disputes-and-evidence.md). A dispute is its own amount-bearing case and deadline lifecycle; it is not a Boolean on the original payment or proof that a refund resolved the issuer process.\n\nUse `go-financial-idempotency` for repeated-request identity, and `go-clearing-settlement-reconciliation` for post-capture external reports and settlement breaks.\n\n## Output contract\n\nProvide the state/event table, authoritative evidence, ambiguity policy, and illegal-transition handling. Do not compress the design into booleans or infer provider success from HTTP status alone.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}