In developing Bitesize Irish Gaelic (the idea was there for a while, but needed to be polished), I decided to use 2Checkout.com as the processor of recurring payments.
Why them? I’ve been using them since 2002 on Irish-Sayings.com and LearnIrishGaelic.com. No fancy stuff, just a landing page that accepts sale parameters.
Since then, they came out with an Instant Notification System (INS). It basically calls a specified script on your sever whenever an order is placed, or when fraud status changes, if it’s cancelled, or if a recurring payment has billed. Basically, an automated way to know what’s being ordered from you and what needs to be fulfilled. They also provide a backoffice API for looking up customer and order information.
Confusing inconsistencies
2Checkout.com calls a Direct Return immediately after each sale is complete. That notifies my server immediately of a new sale. It’s how I can provide the user with instant access to what they buy. Within the next few seconds (or perhaps up to 5 minutes later), and INS call is also made with further details of the sale.
Two services with some overlapping data
The direct return is older than INS, and the INS was developed without, it seems, directly matching what already existed. For example, direct return has an order_number parameter, but INS calls it sale_id (same information). Both are promoted services to developers.
Differing information structures
An INS call is based on the idea of a sale having an invoice and an invoice having invoice items. Great for storing in a database! But guess what, the Direct Return describes product_id, product_id_1*, etc. depending on how many items in the sale, and specifies no invoice number. However, INS describes an invoice number with invoice items item_id_1, item_id_2, etc. What a mess.
The INS API doesn’t do what it promises
Two or three months ago, I gave 2Checkout.com a phone call for the first time. I was testing my billing system built on top Direct Return INS, after learning a lot about their specifications. For some reason, my test purchases were successfully coming in, getting recorded in my database through INS calls, but lacked any information on the recurring sale, contrary to the spec.
For example, the “status of payment” was NULL, the “next bill date” was NULL, and the price for the recurring item was NULL.
Good thing I called them. Turns out that with any PayPal payment (through which I was testing), 2Checkout.com had a bug where it didn’t provide any of this information.
Seriously, if your application depends on 2Checkout.com to keep track of which date each customer has paid up until, it won’t work. Despite the INS specification promising this information, it’s just not supplied.
As of this week, they have confirmed that the bug still exists.
Ways around it
If you’re a programmer, probably you’re thinking, “There’s lots of ways around this bug!“. I agree (and I have already changed my implementation).
The point is, this payment service that processes recurring payments on my behalf can’t even tell me, in line with the documentation, until what date has this customer paid for.