2Checkout is pleased to offer an advance preview of our Instant Notification Service (INS). This service has long been a top request, and we believe there are thousands of 2CO vendors who will benefit greatly from this new service. We wanted to get this in front of you, our vendors, as soon as possible so that we can quickly improve the documentation and support of this service.
INS is, in plain terms, a service which will post sets of cgi parameters to any URL you specify. These posts are each a message containing all the information you need about a specific event (such as when a recurring order re-bills successfully).
This service currently includes the ability to opt-in and receive messages for the following events:
- Recurring Order Stopped
- Recurring Installment Billing Failed
- Recurring Installment Billing Succeeded
- Order Refunded
- Order Canceled
- Order Fraud Status Changed
So what can you do with these messages? Well, please remember that you are getting the very first look at these messages, we do not yet have any prepared add-ons for carts you may be using. We are hopeful that several of the carts out there will be responsive and create add-ons which read in the information from the message and use it to automate some inventory or customer access tasks, making your lives easier. We also hope some of our very talented vendors will create message receiving tools on their own and share them with our community.
We, for our part, will be contacting carts and encouraging them to integrate INS as well as creating some example CGI scripts that our vendors can use as a starting point for integrating these messages into their systems.
The INS Opt-in can only be found within our new Vendor Area, located here. Use your regular username & password from the old Vendor Area to login.
After you are logged in, to get to the INS opt-in page, you need to select the “Account” tab, then the “Notifications” sub-tab. You can also get there directly by using this link after you’re logged in: https://www.2checkout.com/va/acct/ins_settings.
Opting into the INS is as simple as checking the box next to each message you wish to receive, and entering the URL you want it sent to.
Technical specifications detailing each message type and the parameters it will include can be found online here, but we are very interested in receiving your feedback in order to improve it. Please feel free to reply to this post or contact us via the ticket system if you have suggestions or additional questions.
On omission in the current documents has already come to our attention, but rather than the delay this preview while we corrected it, we felt we should move forward with the preview and just add the information here.
The message_type parameter, which indicates the event which triggered the message, can have one of the following values:
- Recurring order stopped
- Recurring installment failed to bill
- Recurring installment successfully billed
- Recurring installment retry successfully billed
- Order refunded
- Order cancelled
- Order fraud status changed
Thank you again for your interest in the 2CO Instant Notification Service and thank you in advance for your valuable feedback!
Sincerely,
2Checkout.com
22 Comments »
+1
-0
You’re getting a great thumbs up from me on this. I hope this includes when a non-recurring digital check order gets validated…
+1
-0
This is great! Exactly what we have been waiting for!
+1
-0
This is absolutely fantastic. This has made my WEEK!
One question though… how do we go about actually testing this? Sure I can set up a 1 month recurring test product… but do I really have to wait a full month until 2CO posts back to my INS designated page?
Is there anyway I can quickly test INS without having to wait for recurring events to occur? Thanks!
+0
-0
There is no feature to test the INS system without an event taking place at this time. I have placed a request with our developers for a test feature.
+1
-0
I am currently developing my php/mysql script to work with 2CO’s INS.
Few Questions that are unclear after reading/analyzing the documentation.
1) In your many examples of various events and their parameters passed back to a vendor’s script, no where is the “required” parameters ‘message_type’ or ‘message_id’ visible. Since they are required parameters, why are they not in the examples?
2) I’m having confusion with the parameters you list with the # sign at the end, (ie. item_name_#). I am guessing that if the recurring order for instance, has multiple items that are going to be billed, there could be numerous instances of each of these kind of parameters? For example…
If John Smith ordered two of ‘Widget A’ ($10/ea.) and one of ‘Widget B’ ($12/ea.) and this order is to be billed recurring every month, then I will see these parameters passed back to my script:
item_name_1 -> Widget A
item_name_2 -> Widget B
item_id_1 -> 123
item_id_2 -> 456
item_quantity_1 -> 2
item_quantity_2 -> 1
item_duration_1 -> 1 Year
item_duration_2 -> 1 Year
item_recurrence_1 -> 1 Month
item_recurrence_2 -> 1 Month
rec_list_amount_1 -> 20.00 *** ????? ****
rec_list_amount_2 -> 12.00
3) I have NO IDEA what the parameter ‘rec_list_amount_#’ is exactly. This one you guys gotta clarify better. Is it a price of the TOTAL recurring order, or is it the total price of just one specific item (depending on how many QTY), or is it the 1QTY price of each item? You see how this is confusing?
Those are the big ones I need some clarification on. Hope this helps out some others! Thank you so much for making INS available… can’t wait to use it.
+0
-0
These are good questions merchantman, I can clarify these for you.
1) Updates to the documentation will be made and these parameters will be included in the example.
2) You are correct about the parameters that have _# at the end. However, if your customers purchased a quantity of 2 ‘Widget A’ for 10.00 each you would receive item_quantity_1 -> 1 and item_quantity_2 -> 1 with a corresponding rec_list_amount_1 -> 10.00 and rec_list_amount_2 -> 10.00 for that situation.
3) The rec_list_amount_# parameter is the price of 1 line item on your sale. This will be the price of 1 of the products that are in the recurring sale. This will always be listed as the price of 1 product because of what was explained in the answer to question #2. The ‘list_amount’ parameter is the grand total for the sale.
+0
-0
Hey Joel, Thanks for answering those questions!
Is there anyway to test or demo INS w/ 2CO, other than setting up a demo order and waiting 24 hours for the recurring events to take place? Is there anyway to trigger these INS events for testing purposes? Thanks!
+0
-0
There is no feature to test the INS system without an event taking place at this time. If you have current sales on your account you can turn on the feature and you will start receiving posts to your scripts as soon as the events take place. I have placed a request with our developers for a test feature.
+0
-0
Thanks Joel.. I notice in the documentation that many parameters with text values have html equivalents in them (in the examples):
ie. ship_street_address => 123%20Main%20St.
Is this an oversight in the documentation, or will the posted parameters really contain these html equivalents that we will need to take into consideration? I can understand why there might be equivs if the form was submitted through GET, but not POST. Any insight is appreciated. Thanks!
+0
-0
This is only a documentation error. The parameters will be posted to your site with spaces and not HTML equivalents.
+0
-0
Hello,
I’m a developer and I want to make a simple payment (not a recurring payment), doesn’t matter the product.. Let’s say I have to pay $20 to a vendor here. Does the current INS announce me that my payment is successfull?
I have to update the status of the payment in my database. It will work for my payment? How can I test this?
+0
-0
I recommend that you implement an Approved URL on your account. This will be the location that the customers are sent after the sale. If your just going to have customers make a simple non recurring payment this will be your best option. A post to your approved URL will tell you that the sale has been successful. Instructions on how to set your approved URL can be found here.
+0
-0
What happens, if seller site “not available” during subsequent reccuring notification?
Will it be resent? Will it be logged separetly at 2co interface, to fix expired goods manually?
+0
-0
At this point the INS post to your script will be tried 3 times. If the INS post fails we will attempt the post about 5 minutes after the first post and then again about 5 minutes after the second post.
This INS post will not be logged in the interface as a missed post. I do feel this is a good suggestion and will speak to our developers about a feature like this.
CORRECTION: The INS posts will be tried 30 minutes after the first post failed and if that 2nd attempt fails we will try again 30 minutes later. This has been increased from 5 as I incorrectly posted earlier today.
+0
-0
Thanks, Joel, it would be really nice.
For example, provider can have problems, and that will cause missing of 10 notifications.
Next day I’ll get problems with 10 angry users with broken permissions
. But if missed notifications are recorded, I can rebuld information manyally and very fast.
Second option is to send failed notifications via email, don’t foget to propose it
+0
-0
When will 2checkout recurring payments be compatible with WHMC ??!
+0
-0
You may want to read Selling Recurring Products With 2Checkout
Recurring products only work when using the Plug and Play parameter set. Some shopping carts offer integration with this parameter set, to allow this functionality. Unfortunately, we cannot integrate this functionality into a 3rd party cart, but we are happy to work with 3rd party cart makers to provide them with the information they need to do so.
If WHMC does not wish to add this functionality, you may, of course, contact us directly and we will be happy to help you find another way to use recurring payments.
+0
-0
We’ve enabled the INS service and added the url via admin panel, but we are experiencing one problem. For some reasons we get all the notifications except Fraud Status Changed.
We submitted a support ticket regarding this issue (1949-RTAX-5721) 11 days ago and every time we get the same answer “I apologize but our developers are still working to determine the cause of the issue you encountered” :(((
+0
-0
Hello amex - Sorry about the delay in response to you. Our developers have found an issue with the Fraud Status Changed message that was preventing it from sending. This issue will be fixed shortly and the message will send once this fix has been completed.
+0
-0
I just signed on and I am a developer. Looking at the Notification Tab in my Admin, I notice that we have “message_type=SHIP_STATUS_CHANGED ” for instance.
Having a PHP background, items like “SHIP_STATUS_CHANGED” are constants that hold values and this is a cause of confusion here.
Will the posted message literally hold “SHIP_STATUS_CHANGED” or will “SHIP_STATUS_CHANGED” actually be a constant holding a value. If so, developers need to know what those values are so as to be able to write code to check.
I ned to know this so I
+0
-0
Each INS post will send you a parameter that describes the message type you are receiving. “SHIP_STATUS_CHANGED” will be the value of the “message_type” parameter for this particular message. “SHIP_STATUS_CHANGED” will not hold any values as it is the value of the “message_type” parameter for this message. Full details of what values each parameter will hold can be found in the INS documentation here.
+0
-0
Got that.
Thanks