PayPal IPN Handling Improvements

With SubscriptionBoss 1.31 the PayPal IPN processing was updated in line with the latest PayPal recommendations.

A few users have reported issues recently with an increase in the number of duplicate IPNs being sent by PayPal. The resending of the IPNs is symptomatic of the acknowledgements not being received by PayPal in a timely fashion. It is hoped that the new version will offer greater reliability to those users that have had issues with duplicate IPNs.

Acknowledging Receipt Of PayPal IPNs

This involved a few changes to the way in which the acknowledgement of receipt of the IPN is built and returned to PayPal.

• PayPal IPN values are read from php://input rather then POST variables
• Magic quotes settings are checked before slashes are stripped
• if present, the “_REPEATED” variable is stripped before the acknowledgement signature is created
• CURLOPT_FORBID_REUSE is set to prevent connection caching
• CURL_HTTP_VERSION is set to CURL_HTTP_VERSION_1_1

Other IPN Handling Enhancements

While revisiting this area, a few other minor improvements were introduced

More Accurate Transaction Dates

In previous releases, SubscriptionBoss used the time the IPN was processed as the transaction date. Now it searches the IPNs and uses the payment date for payments and refunds. This means the date recorded in Infusionsoft reflects the actual date and time the PayPal payment or refund took place.

Duplicate IPN Checking

Duplicate checking used only to take place for IPNs involving payments or refunds. This meant that duplicates of payment failure, profile creation and cancellation IPNs resulted in duplicate records in the database. Now all IPNS are subject to checking for duplicates.

IPN Processing Logic

The algorithm for handling IPNs in general and Payment Driven Orders in particular has been streamlined and made more robust:

• Is this IPN for a product/subscription that is handled by SubscriptionBoss?
• Is this IPN for a payment, refund, payment failure or cancellation?
• If a cancellation, then try and process the cancellation
• If a payment failure, then try and process the failure
• If a refund, then try and process the refund
• If a payment and its status is completed then try and process payment
• If payment processing fails as there is no order or invoice available yet, and payment driven orders are enabled, and this IPN is for an subscription that has an order matching rule then try and create an order for this IPN and process the payment

Payment Driven Orders Improvements

The above changes fix some issues with Payment Driven Orders:

• Prevent duplicate order creation if subsequent payments arrive before the associated invoice is generated
• Prevent possible running of wrong action set when several subscriptions have very similar names