Upcoming Changes to CCBill Subsc ID Format

Will this affect aMember <--> CCBill Payment integration?

The mesg below is quoted from the latest client group announcement from CCBill:

"Dear CCBill Client:

In an effort to improve the performance and redundancy of our transactional processing systems, we will soon institute a change in the numbering convention of our Subscription Identification (ID) Numbers. This change is important for you to note especially if your website(s) and/or system scripts are written to include our CCBill Subscription ID numbers.

In order to accommodate this update, please plan to make the appropriate changes to your systems by the scheduled implementation date of Thursday, September 7, 2006.

PLEASE NOTE: This change will not influence the historical subscription and reservations ID's prior to the above implementation date.

The following CCBill Client accessed systems will be affected by this change:

1) System5 Web Admin
2) Client Affiliate System
3) DataLink Subscription Management System
4) Subscription Notification Systems (Email, Background & Approval Posts)
5) Subscription Upgrade System

With this change, CCBill Subscription ID's will support the following new format:

0006100101000000001 - First 2 Digits are the Station ID
0006100101000000001 - Digits 3-4 are the last 2 digits of the current year
0006100101000000001 - Digits 5-7 are the Julian Date
0006100101000000001 - Digit 8 is the Day of the Week (1=Monday, 2=Tuesday, 3=Wednesday, 4=Thursday, 5=Friday, 6=Saturday, 7=Sunday)
0006100101000000001 - Digits 9-10 are the Payment Method (1=Credit, 2=Test, 3=User Management, 6=ACH,7=Telephone Billing)
0006100101000000001 - Digits 11- 19 are the Subscription ID unique to current station ID and Julian Date

If you have any questions regarding this change in the CCBill Subscription ID format, or any other CCBill product or service, our Client Support team is available 24 hours a day, 7 days a week to assist you. They can be reached toll free at 800.510.2859"


My understanding is that aMember simply stores the subscription ID and that was it. aMember did not use the sub ID in any other way than storing it (except comparisons thru cron feeds). This would lead me to believe there should be no complications with this upcoming change, but I could be wrong. Perhaps if the like the storage length for this field needed to be increased or something like that in the aMember DB or code.

I've been doing a lot of internal aMember code assessment myself, and from what I can tell, CCBill's change should not affect things. It's always best though to get a real read from the actual person most familiar with the code

I mean, all CCBill is doing is extending the size format of the subscription ID field. I can't imagine where this might cause problems for aMember, unless parts of the code expect for the subscription ID field to be within a certain length.

Do you think we'll have a better assessment of what to be prepared for before CCBill implements this live all across the board in 1 month?

On a related note for recent CCBill EU-Debit options, I did a customized implementation, so I'll be testing this and seeing if it can work with the current aMember s/w (when products/pricing are tuned to fit their Euro options). Looks like the only issue I can forecast is inconsistency with aMember's own internal reporting of revenue since everything within aMember is confined to one currency more or less for internal usage (ie. the one currency that is specified in aMember's advanced config), but it will not affect how CCBill processes or charges Euro or USD to customers though if configured right.

Some of the URL field generation fed to CCBill would be beneficial to have modified such as the GET VARS for "allowedCurrencies", "language", and slightly modified "allowedTypes" & "subscriptionTypeId" which append "allowedCurrencies" on the end of them with a colon ":" in between. Those changes aren't absolutely necessary, but they do seem to allow the CCBill transaction pages to generate more smoothly, especially if you have a variety of products where different currency & pricing offerings could cause CCBill page generation conflicts.

The old URL format will still work w/CCBill, it's just that parts of the purchase process might require additional, but fairly self-guiding steps for the consumer to take in order to complete the transaction (luckily CCBill's forms use javascript to automatically request their additional clarification GET VAR for "allowedCurrencies").

Can you keep us updated if there will be problems due the ccbill ID changes ? Hopefully they don't affect amember ! fingers crossing