You can cancel a previously created payout if its status is pending
. Stripe refunds the funds to your available balance. You can’t cancel automatic Stripe payouts.
Parameters
No parameters.
Returns
Returns the payout object if the cancellation succeeds. Returns an error if the payout is already canceled or can’t be canceled.
{ "id": "po_1OaFDbEcg9tTZuTgNYmX0PKB", "object": "payout", "amount": 1100, "arrival_date": 1680652800, "automatic": false, "balance_transaction": "txn_1OaFDcEcg9tTZuTgYMR25tSe", "created": 1680648691, "currency": "usd", "description": null, "destination": "ba_1MtIhL2eZvKYlo2CAElKwKu2", "failure_balance_transaction": "txn_1OaFJKEcg9tTZuTg2RdsWQhi", "failure_code": null, "failure_message": null, "livemode": false, "metadata": {}, "method": "standard", "original_payout": null, "reconciliation_status": "not_applicable", "reversed_by": null, "source_type": "card", "statement_descriptor": null, "status": "canceled", "type": "bank_account"}
Reverses a payout by debiting the destination bank account. At this time, you can only reverse payouts for connected accounts to US bank accounts. If the payout is manual and in the pending
status, use /v1/payouts/:id/cancel
instead.
By requesting a reversal through /v1/payouts/:id/reverse
, you confirm that the authorized signatory of the selected bank account authorizes the debit on the bank account and that no other authorization is required.
Parameters
- metadatahash
Set of key-value pairs that you can attach to an object. This can be useful for storing additional information about the object in a structured format. Individual keys can be unset by posting an empty value to them. All keys can be unset by posting an empty value to
metadata
.
Returns
Returns the reversing payout object if the reversal is successful. Returns an error if the payout is already reversed or can’t be reversed.
{ "id": "po_1Oj6B8rU4sY9X3L2mQ6T5fZ1", "object": "payout", "amount": -1100, "arrival_date": 1680652800, "automatic": false, "balance_transaction": "txn_1O5G7H8k1p2Q9a6c0N8elkI0", "created": 1680648691, "currency": "usd", "description": null, "destination": "ba_1MtIhL2eZvKYlo2CAElKwKu2", "failure_balance_transaction": null, "failure_code": null, "failure_message": null, "livemode": false, "metadata": {}, "method": "standard", "original_payout": "po_1OaFDbEcg9tTZuTgNYmX0PKB", "reconciliation_status": "not_applicable", "reversed_by": null, "source_type": "card", "statement_descriptor": null, "status": "pending", "type": "bank_account"}
Refund objects allow you to refund a previously created charge that isn’t refunded yet. Funds are refunded to the credit or debit card that’s initially charged.
Related guide: Refunds
ConfirmationTokens help transport client side data collected by Stripe JS over to your server for confirming a PaymentIntent or SetupIntent. If the confirmation is successful, values present on the ConfirmationToken are written onto the Intent.
To learn more about how to use ConfirmationToken, visit the related guides:
Tokenization is the process Stripe uses to collect sensitive card or bank account details, or personally identifiable information (PII), directly from your customers in a secure manner. A token representing this information is returned to your server to use. Use our recommended payments integrations to perform this process on the client-side. This guarantees that no sensitive card data touches your server, and allows your integration to operate in a PCI-compliant way.
If you can’t use client-side tokenization, you can also create tokens using the API with either your publishable or secret API key. If your integration uses this method, you’re responsible for any PCI compliance that it might require, and you must keep your secret API key safe. Unlike with client-side tokenization, your customer’s information isn’t sent directly to Stripe, so we can’t determine how it’s handled or stored.
You can’t store or use tokens more than once. To store card or bank account information for later use, create Customer objects or External accounts. Radar, our integrated solution for automatic fraud protection, performs best with integrations that use client-side tokenization.