GoFuckYourself.com - Adult Webmaster Forum - View Single Post

apson · 04-07-2006, 10:04 PM

Attn developers/processors:
I'm in the process of integrating processors into a custom back-end. We have paycom, gxbill, and wts integration done, but need an additional cc biller to complete the cascade. I've been going through ccbill docs for a day and there just isn't enough data there (in the postback OR the data link extract) to create something reliable. The rebill reports contain no unique transaction identifiers and the passback doesn't contain any information about the selected payment option. The only hack for this would be creating a new "sub-account" for each payment option. Is this what people do? I will not rely on session variables to determine something as trivial as the payment type. Either 1) are there any known (but undocumented) vars in the ccbill passback that contain the payment type (in any form, even the form name) or 2) has anyone tackled back-end work with ElectraCash or Jettis and how do those perform? If any enterprise-level developers could point me in the right direction it would be great.

Also -- do most of these processors maintain their own acidity with regard to password management vs postback? Right now we're just using the password management functions to verify the availablity of usernames and to disable the accounts of expired users. You can see the issues that might arise here if these processors aren't maintaining isolation on their end (which judging by the looks of some of these password management scripts, they are not).

04-07-2006, 10:04 PM
apson Registered User Join Date: Apr 2006 Posts: 4	CCbill and Paycom cc alternatives Attn developers/processors: I'm in the process of integrating processors into a custom back-end. We have paycom, gxbill, and wts integration done, but need an additional cc biller to complete the cascade. I've been going through ccbill docs for a day and there just isn't enough data there (in the postback OR the data link extract) to create something reliable. The rebill reports contain no unique transaction identifiers and the passback doesn't contain any information about the selected payment option. The only hack for this would be creating a new "sub-account" for each payment option. Is this what people do? I will not rely on session variables to determine something as trivial as the payment type. Either 1) are there any known (but undocumented) vars in the ccbill passback that contain the payment type (in any form, even the form name) or 2) has anyone tackled back-end work with ElectraCash or Jettis and how do those perform? If any enterprise-level developers could point me in the right direction it would be great. Also -- do most of these processors maintain their own acidity with regard to password management vs postback? Right now we're just using the password management functions to verify the availablity of usernames and to disable the accounts of expired users. You can see the issues that might arise here if these processors aren't maintaining isolation on their end (which judging by the looks of some of these password management scripts, they are not).