How can I avoid re-running code when exceptions are thrown and user re-submits?

Question

I have a checkout process that 1) creates a user account in Stripe and my database, 2) creates a paymentMethod in Stripe and logs the last4 in the database, 3) creates the subscription in Stripe and logs the subscription to database, 4) sends welcome email and creates a job record in the database to build the service for the subscription.

However, during this process, a lot can go wrong. Some of the things I can think of are: 1) credit card number is invalid, card is declined, API rate limiting, database server goes down/overloaded, etc...

I'm using a try/catch in PHP. However, how can I avoid re-running parts of the try if the user simply needs to fix some input like using a different card number because the other one declined?

At this point the customer record is already created, so I don't need to re-run those parts.

try {
- 1
- Create Stripe Payment Method
// this will throw any credit card validation errors such as invalid dates, csc, etc...

- 2
- Create Stripe Customer
- Attach payment method to Customer
- Create record in database for customers table

- 3
- Create Stripe subscription
- Create record in database for subscriptions table

- 4
- Create record in job table to send out welcome email and build service for customer 

- display thank you page
} catch 
- Stripe CreditCard validation
- Stripe API Rate Limit
- Stripe API network error
- other Stripe error handling
- PDO Exceptions
}

Should I create a session variable for each section and use an if block of code to prevent re-running it?

For example if section 2 completes, do something like $_SESSION['customer'] = 'done'; and then do:

 if ($_SESSION['customer'] == 'done') { 
   // don't run
 } else {
   // run code

    $_SESSION['customer'] = 'done';
 }

Answer 1

Work out what different states the system can end up in, e.g. "Not started yet" or "Stripe customer created but no subscription".

Store the state for each user in your database.

Break down your logic into chunks so that, no matter what state you end up in, you never need to run only part of a chunk.

When you process a request, first check the current state. That will tell you what chunks of logic you need to run, and which you can skip. After running a chunk of logic, update the current state - which will be different depending on success or failure.

Answer 2

Payment processing is a touchy subject. It is very important to have a solution that prevents multiple submits, is resilient to failure, and provides auditability in case of dispute. This is not just for the benefit of your business, but also for compliance purposes, if you take CC payments.

To achieve this, your business model should include an entity which could be called "Sales Order." This entity would contain, among other things,

1. A unique order ID
2. Customer ID
3. Order create date
4. Payment date
5. Fulfillment date
6. Payment method ID
7. Payment identifier, such as a confirmation code
8. Fulfillment identifier, such as a Shipping Order ID or a delivery tracking code

When the customer places the order, create the record.

When you collect payment, update the payment date and the confirmation code.

When the item ships, update the shipping ID or tracking code.

Etc.

Basically you have to update the record each and every time one of the steps in your workflow is completed.

By looking at all these fields, your system can figure out which steps have been completed and which ones have not. For example, if the payment date is set, it knows that payment has already been collected; if it is null, payment still needs to be collected.

This will allow you system to pick up where it left off when the order is resubmitted, and provides all the information your customer support department will need in case there is a dispute.