|Using different credit card processor than authorize.net|
|Using different credit card processor than authorize.net|
Author rebima on 04-13-2001 at 15:59 (EST)
|Hello, I just recently purchased storekeeper. Unfortunally it works easy with authorize.net or linkpoint. I have allready another credit card transaction manager. I do also have the neccessary script what this account need. How, and where can i implement the sertain script in the cgi. Or where can i change the cgi that the final amount and all other data fields goes from my secure server to his approval secure server?
|Table Of Contents|
| RE: Using different credit card processor than authorize.net Bill Weiner, 2001-04-17 06:51:34 (1)|
| Credit card interfaces reto bianchi, 2001-04-18 08:34:49 (2)|
| RE: Credit card interfaces Bill Weiner, 2001-04-19 05:16:36 (3)|
| creditcard interface reto bianchi, 2001-04-19 09:55:10 (4)|
| RE: creditcard interface Bill Weiner, 2001-04-20 05:41:40 (5)|
| RE: creditcard interface Bill Weiner, 2001-04-20 05:45:09 (6)|
| credit card interface reto bianchi, 2001-04-20 09:06:59 (7)|
| RE: credit card interface Bill Weiner, 2001-04-24 22:07:53 (8)|
| credit card processor reto bianchi, 2001-04-25 07:37:51 (9)|
| RE: credit card processor Bill Weiner, 2001-04-25 22:32:16 (10)|
|Messages In This Discussion|
| 2. Credit card interfaces|
Author reto bianchi on 04-18-2001 at 08:34 (EST)
|The code for https form tags for my transaction manager looks like this:|
And then the different hidden type like AMOUNT,MERCHANTID, CREDITCARD# etc.
So, if i can only link those or if i be able to transfere the collected data from storefront to a normal reconized data field then i would be able to send those. I have different ways to send data,s. I mean i can send the minimum requirement or even more, thats up to me. A standard query string would look like the following example:
Do i have any change to use storfront for this?
| 3. RE: Credit card interfaces|
Author Bill Weiner on 04-19-2001 at 05:16 (EST)
|It looks like your HTML did not get posted to this forum correctly.|
But in any case, posting the data to an external payment processing system isn't the hard part... the hard part is customizing the script to handle the success/fail response back from the payment processing system.
That is, you could try setting the "CUSTOM" payment option to "YES" and then implement the "get_custom_payment_button_html" subroutine in the ushop.pl file to pass whatever data you want to the payment processing system. But if the system will be returning a success/fail response to you, you will also need to customize the "complete_order" subroutine that is also located in that ushop.pl file.
| 4. creditcard interface|
Author reto bianchi on 04-19-2001 at 09:55 (EST)
|Thank you for your help. But i do not have any ushop.pl files. |
You mentioned that in the get-custom-payment-button-html i can pass whatever i like to the payment processing system. I assume this would be by credit card order, right?
I try to post a sample again what kind of data i have to pass: "//secure1.merchantmanager.com/apcgateway/ccgateway.asp?requesttype=approvalonly&merchantid=mystore123&bname=mr+bigger&ccnumber=4013309766478541&expmo=12&expyr=1999&baddress1=456+B=st&bzipcode=92677&amount=15.99"
Should i implement those infos on the subbmit button by the credit card order form?
| 5. RE: creditcard interface|
Author Bill Weiner on 04-20-2001 at 05:41 (EST)
|Oops. Sorry about that. I forgot you were referring to uStorekeeper rather than uShop.|
Implementing a new payment processing system interface into uStorekeeper would involve modifying the "review_order" subroutine of the "ustorekeeper.pl" file. In particular, I would suggest doing a search on:
if ($settings =~ /yes/i)
...which will get you to the start of the Authorize.Net HTML/parameters. I would then try modifying those parameters to post the parameter names that your payment processing system needs.
You may also need to modify the "authorize_net_order" subroutine (or create a new subroutine) to handle any approved/declined response that your payment processing system may return.
Again, developing a new interface is never easy...and would require that you are comfortable with Perl programming.
| 6. RE: creditcard interface|
Author Bill Weiner on 04-20-2001 at 05:45 (EST)
|Looking at the parameters that you listed in your previous posting... it appears that you need to pass the credit card information to your payment processing system too. This would mean that rather than modifying the "review_order" subroutine as discussed above, you would probably need to make your modifications to the "create_credit_card_form" and "credit_card_order" subroutines.|
| 7. credit card interface|
Author reto bianchi on 04-20-2001 at 09:06 (EST)
|I am not so familiar with perl. Does uburst offers someone who could change the subrutine to my needs in order to make sure that everthing works. Otherwise i would have spend a lot of money for nothing, and i would regret it because i really like the ukeepstore. I cant belive that all that happens, because of one handshake. I mean, if i have to spend some more money to get it run, i can life with that rather than put ustorekeeper in the trash.
| 8. RE: credit card interface|
Author Bill Weiner on 04-24-2001 at 22:07 (EST)
|In addition to the interfaces listed at:|
....we are already working on various other payment processing interfaces. The order by which we develop these interfaces is based on the demand we get for each interface. What is the name of the payment processing system you want to use?
| 9. credit card processor|
Author reto bianchi on 04-25-2001 at 07:37 (EST)
|The payment processing is called merchantmanager.com (I think this one is handled by Accesspoint.com)Thank you for your responce.|
I hope you guys have a solution soon. Then i really should implement my spare parts in my website.
| 10. RE: credit card processor|
Author Bill Weiner on 04-25-2001 at 22:32 (EST)
|I just added "MerchantManager" to our payment processing interface wish list... but unfortunately, since you are the only person to request that interface so far, it's pretty much at the bottom of the list. And really, we won't be able to even start the interface until we get enough other requests to justify the development time.|