Two of the most significant additions to Checkout in 2025 were automated reversals and event notifications. Both features enable reactive, intelligent payment handling that reduces manual work and enables seamless integration with external systems.
Automated reversals
One of the most significant features introduced in 2025 was automated reversals, launched in public beta in June. This feature allows automatic reversal of payments based on configurable predicates when the order-creation process fails.
Use cases for automated reversals
Automated reversals are valuable in scenarios such as:
- Fraud detection: automatically reverse payments flagged as fraudulent by scoring systems
- Inventory unavailability: reverse payments when inventory checks fail after payment authorization
- Business rule violations: reverse payments that don't meet business criteria (for example, restricted shipping countries)
- Integration failures: reverse payments when downstream systems, such as Enterprise Resource Planning (ERP) and Order Management Systems (OMS), can't process orders
- Regulatory compliance: automatically reverse payments in restricted scenarios based on compliance rules
Configuration and predicates
You can use automated reversals together with Payment Integration predicates that define when reversals should occur. Predicates are logical expressions using JSONata query syntax that evaluate to true or false based on payment context.
When your predicate evaluates to true, the system processes the automated reversal for that payment. When it evaluates to false, the payment continues without reversal, allowing the transaction to proceed normally.
Predicate examples for automated reversals
This predicate triggers reversal if the cart total is over 100,000 cents (1000 EUR), the customer is new, and has a high fraud score:
payment.amount.centAmount > 100000 and customer.type = "new" and fraudScore > 0.8
This predicate triggers reversal if the shipping country is restricted:
shippingAddress.country = "IR" or shippingAddress.country = "KP"
This predicate triggers reversal if the customer group is on a watchlist:
customerGroup.id = "suspended-accounts-group-id"
This predicate checks that the customer group ID is a specific value and the billing address country is Germany or Netherlands:
customerGroup.id = "aef9cf41-94ad-4794-8122-62d308900430" and (shippingAddress.country = "NL" or shippingAddress.country = "DE")
You can see the detailed steps of setting predicates for automated reversals here.
Reverse a payment
We enhanced the Payment Intents API to support the
reversePayment action. For complete API details, see the reverse payment documentation.Benefits
Automated reversals provide:
- Reduced manual work: eliminates need for staff to manually identify and reverse problematic payments.
- Faster resolution: reversals happen immediately when conditions are met, reducing refund processing time.
- Consistency: predicate-based logic ensures consistent application of business rules across all transactions.
- Audit trail: all automated reversals are added as new Transaction objects inside the original Payment object.
- Customer experience: faster resolution of issues improves customer satisfaction and reduces support burden.
- Risk management: proactive reversal of suspicious payments reduces fraud exposure.
Event notifications
In June 2025, we introduced event notifications for Checkout in public beta. This feature provides webhook-style notifications for checkout events, enabling better integration with external systems and business processes.
Event types
Event notifications cover a wide range of checkout activities:
- Order events: for Order creation failures
- Payment authorization events: for successful and failed authorizations
- Payment capture events: for successful and failed captures (charges)
- Payment cancellation events: for authorization cancellations and failures
- Payment refund events: for successful and failed refunds
Subscription and configuration
You set up event notifications using the Subscriptions API, which is separate from the Checkout API, by defining where you want to receive the notifications—typically a message queue. This approach lets you handle events in the background, so your checkout process isn't delayed waiting for event processing to complete.
To subscribe, create a SubscriptionDraft with the
events field containing the desired EventTypes with resourceTypeId set to "checkout":{
"destination": {
"type": "GoogleCloudPubSub",
"topic": "Topic",
"projectId": "<project-id>"
},
"events": [
{
"resourceTypeId": "checkout",
"types": [
"CheckoutPaymentRefunded",
"CheckoutPaymentRefundFailed",
"CheckoutPaymentCharged",
"CheckoutPaymentChargeFailed",
"CheckoutOrderCreationFailed"
]
}
]
}
Then, post this SubscriptionDraft to the Create Subscription endpoint.
You can check the complete event structure and payload details at the Checkout Events documentation.
Integration scenarios
Event notifications enable various integration scenarios:
- Analytics: stream checkout events to analytics platforms for funnel analysis and conversion tracking.
- Business intelligence: feed checkout data to BI systems for reporting and dashboard creation.
- Fraud detection: send payment events to fraud detection services in real-time for immediate action.
- Inventory management: trigger inventory reservations when payments authorize, release on failures.
- Marketing automation: update customer profiles and trigger campaigns when checkouts complete.
- Monitoring and alerting: monitor checkout health metrics and alert on anomalies or failure spikes.
- Order management systems: notify OMS of successful orders for fulfillment processing.
- Accounting systems: sync payment events with accounting software for reconciliation.