paid: true leaves a lot unanswered. Has the provider accepted the request? Has the customer completed authentication? Is the payment captured, settled or later refunded?
The sequence gets awkward when systems disagree. A webhook can arrive before the API response. The client can time out while the provider succeeds. The same event can arrive twice. I’d make those cases explicit rather than force them into success and failure.
Define the states and the evidence required to move between them. Record provider references alongside internal IDs. Verify webhooks, keep their event identifiers, and make processing safe to repeat. Don’t let an older event blindly overwrite a newer state.
An unknown outcome needs reconciliation. Ask the provider what happened before inviting the user to create another charge. Keep accounting history intact; a refund or correction is another event, not a reason to erase the original entry.
The support screen should use the same state model. If engineering calls a payment “pending” while support calls it “failed,” the customer gets the disagreement. Clear transitions help everyone describe the same operation.