Improvements To PayPal IPN Processing in SubscriptionBoss 1.34

There were a handful of improvements to the algorithm for handling PayPal IPNs.

Please note you need to be running at least PHP 5.3

They covered a number of issues:

• Potential addition of duplicate payments to invoices when either the WordPress site or Infusionsoft was running really slowly
• Payment dates being in UCT or Greenwich Mean Time (+00:00) instead of Eastern Standard Time
• New Order actions and Payment success actions both running for payment driven orders
• Cancellation actions not running for payment driven orders
• Payment Failure actions not running for payment driven orders

IPN Queueing

SubscriptionBoss now has a queueing mechanism so only one thread is processing IPNs at any time. This removes reliance on Infusionsoft threading and the potential of a cache indicating that an IPN is unprocessed to two or more threads at the same time. This should remove the potential of the same payment being added twice.

EST Time

SubscriptionBoss now converts all times (payment dates, etc) to Eastern Standard Time which is a requirement of Infusionsoft which was not observed until this release.

Processed IPNs And Running Action Sets

SubscriptionBoss used to run an action set based on a binary decision on whether or not an IPN was “processed”. Now it is more nuanced and will only run an action set if the event caused a change to take place within Infusionsoft.

Now there are 4 processing status values

1. Processed – SB has updated something – e.g. added a payment, refund, etc
2. Already processed – we have already processed this IPN – e.g. applied this payment
3. No processing required – this is an unknown product, subscription or transaction type – we cannot process this IPN
4. Unprocessed – we think will be able to process this IPN later, once Infusionsoft has created a invoice for this subscription so we’ll park it for now and process again later

From now on, an action set will be run only on the the first of the above four scenarios.

Also, SB now handles the subscr_cancel and subscr_failed transaction types so both cancellations and payment failures for legacy subscriptions cause the relevant action sets to run.