Ordergroove will retry all payment requests that return a 140 error response a set number of times based on your store settings. The first retry will take place 3 days after the initial attempt, and the last retry will take place 3 days after the first retry attempt. The customer will receive an email trigger to update their payment method between attempts (pending setup in Ordergroove). You must ensure the 140 response is correctly mapped for your order placement endpoint. If all retries fail or the customer clicks send now for the same item(s), the original order is marked as rejected.
If you do not want an order to be retried with this flow, you will need to use the 160 error response which indicates no retries should be attempted.
Note: Ordergroove may cancel the customer's subscription after repeated rejections based on Disengaged Subscriptions configurations.
Please refer to the detailed flowchart below for additional context. Click here for the full-size resolution.
What happens when a customer updates their credit card?
When a customer updates their credit card, an order that is already in the retry flow will wait until it's next scheduled retry attempt before Ordergroove charges the card again. You can use Auto Retry to process the new payment method immediately.
Feature Availability: Auto Retry is currently in Early Access, please reach out to your CSM or Ordergroove Support if interested.
With Auto Retry, Ordergroove instead attempts payment as soon as the customer successfully updates their payment method—restoring the subscription sooner rather than waiting for the next scheduled attempt.
When Ordergroove detects a successful payment method update, it immediately retries any of that customer's eligible orders currently in a retry state. If the payment succeeds, the subscription resumes its normal lifecycle. If it fails, the order continues through the standard retry schedule described above.
Auto Retry only applies to orders that are actively in a retry state. Orders that have already exhausted the retry flow and been marked as rejected are not affected, and your standard retry rules and payment safeguards continue to apply.
Note: If you currently listen for payment update webhooks and manually trigger Send Now (or another retry mechanism), disable those workflows to avoid duplicate payment attempts.
You should also review any customer-facing messaging that tells customers to wait for the next scheduled retry or to expect a charge in several days, since a charge may now happen immediately after they update their payment method.