Launching a start up is an amazing experience, in the last few months I've written code in many different areas to facilitate the successful and smooth launch to come. As mentioned in previous posts the last step of getting my commercial site up and running involved coding the consumer web site and providing users the ability to browse and select or upgrade to any of the service plan options that my site makes available.
In this post, I discussed some of the ways that I was able to efficiently handle problems that consumer sites enabling e commerce run into. Basically, a trade off must be made does the site manage every aspect of the service plans that users purchase by keeping subscriptions? If so where is the subscription information managed? In a proprietary method on the consumer site or is that function off loaded (at cost) to a third party payment processor? In the ideal I would design and build my own payment processing API, get a merchant account for handling credit cards and process them directly but time and cost constrains preclude such an action. A second option is to perform the service plan set up and off load the payment processing to a third party company like Paypal or Amazon or another payment service.
This is what I decided to do but soon ran into the Gordian knot that was Paypal's payment services API. I like a good puzzle but nothing pisses me off more than a puzzle that that makes no sense, that changes the rules as you go along or that is just needlessly complex. The payment services API from paypal has an amazingly complex procedure that requires setting up multiple accounts (paypal business account, client account, sandbox business account, sandbox client account) and then goes further to require that various accounts are actively logged in to the testing machine while testing....this is not so bad if the accounts didn't have such short time outs. I'd be in the midst of testing a change only to have to re-login, I'd get browser windows confused as I was logging into to the wrong accounts....I spent more time book keeping than testing the code I was writing and this says nothing of the appaling documentation that paypal has.
Rather than providing detailed use cases and code examples, it provides page after page of numbered instructions which again is not so bad but code samples are always better. I got to a point where a user on my site would click a service plan option and that would take them to the paypal login screen, the sandbox account would then be logged into (while the sandbox business account is logged in as well..they never explain why this must be the case) at this point the user should be prompted to enter credit card information, review the selected plan and then submit but I was never able to get past a single cryptic message. Posts to the Paypal developer forums went unheeded by the paypal developers who seemed to be actively answering the questions of others. After 3 days of waiting for a reply I gave up on Paypal.
Enter Amazon
I had to take a few days off after wrestling with Paypal's draconian system and in that time looked into my other options. Amazon , I recalled at recently began offering payment services through their AWS (Amazon Web Services) program. I investigated their offerings and noticed that they did have "pay now" services but unlike Paypal , they didn't have a "subscription" service. Luckily , as explained in In this post my framework provides a more efficient and reliaable way for me to simulate subscriptions. I could simply manage the users account access and duration using my Flags' and use only the "pay now" buttons to allow users to switch between plans or extend service for existing plans at any time.
This way Users can build up credit for their selected service plan in the form of usage days and when desired extend or upgrade their plans. This provides a versatility that neither Paypal or Amazon provided. As I continued to look into implementing Amazon I was pleased to see that their documentation was just slightly better managed than Paypal's but there were still glaring ambiguities in some of the writings. As programmers you think that the importance of syntax and the precise use of words would be something that writers of technical documentation would pay attention to, but not all technical writers are technically minded. Some of the instructions ommitted critical steps that absent would cause transactions to fail, others were plain wrong , still others would use "should" when they really meant "must" as I road the coaster of implementing the Amazon payment services I corrected several document mistakes by pointing them out in threads on the developer central web site.
I had already completed the required code on my end of the interaction, basically , when a user selects a plan the information would be sent securely to Amazon which would display the plan options , allow the user to select their credit card options (or store one with Amazon for use) and then submit the request and then send the user back to my site to a designated return URL. The parameters of the url would indicate the status of the transaction and payment information for the plan selected by the user. All this worked fine when the interaction was NOT signed, Amazon allows transactions to be signed with an encryption signature value generated from the unique attributes sent with a pay request. My site would generate the signature and add it to the outgoing request, Amazon would verify the request came from me by inversing the signature operation with a secret key.
This would guarantee that the request came from my servers and was not tampered with after the code was generated. On Amazon's end , after the user transaction is completed Amazon would then sign the return parameters and add a signature to that affect for my servers to inverse and guarantee came from Amazon. This way the transaction is authenticated at both ends and guaranteed to not have a "man in the middle" changing values either to upgrade services or lower prices without authorization. Unfortunately , the signature verification was not working, I sent out several threads asking for help on the Amazon site and unlike Paypal received answers from Amazon programmers that helped me hone in on the proper solution.
The proper solution involved fixing several errors in the existing Amazon test code (at least they had test code) and adding a convenient method to the test code that does the signature verification (Amazon only provided numbered instructions for this previously, now they have actual working code they can provide to implementer) I finally got the transactions working perfectly, securely and with signed parameters. I must mention that like Paypal Amazon requires the use of a "sandbox" account for the business (a fake business) and a sandbox account for a fake client. These are used to simulate payments when testing the code but unlike Paypal they didn't require that I be logged in on the computer while testing the code from my commercial site (which was bizarre) this allowed me to proceed with testing without getting frustrated at all the logins I had to perform.
Now that the e-commerce enablement is complete I am ready to roll the code out to the production servers....well, almost...there is one feature I wanted to sneak in to the framework...I'll talk about that more in the next post... ;)
In this post, I discussed some of the ways that I was able to efficiently handle problems that consumer sites enabling e commerce run into. Basically, a trade off must be made does the site manage every aspect of the service plans that users purchase by keeping subscriptions? If so where is the subscription information managed? In a proprietary method on the consumer site or is that function off loaded (at cost) to a third party payment processor? In the ideal I would design and build my own payment processing API, get a merchant account for handling credit cards and process them directly but time and cost constrains preclude such an action. A second option is to perform the service plan set up and off load the payment processing to a third party company like Paypal or Amazon or another payment service.
This is what I decided to do but soon ran into the Gordian knot that was Paypal's payment services API. I like a good puzzle but nothing pisses me off more than a puzzle that that makes no sense, that changes the rules as you go along or that is just needlessly complex. The payment services API from paypal has an amazingly complex procedure that requires setting up multiple accounts (paypal business account, client account, sandbox business account, sandbox client account) and then goes further to require that various accounts are actively logged in to the testing machine while testing....this is not so bad if the accounts didn't have such short time outs. I'd be in the midst of testing a change only to have to re-login, I'd get browser windows confused as I was logging into to the wrong accounts....I spent more time book keeping than testing the code I was writing and this says nothing of the appaling documentation that paypal has.
Rather than providing detailed use cases and code examples, it provides page after page of numbered instructions which again is not so bad but code samples are always better. I got to a point where a user on my site would click a service plan option and that would take them to the paypal login screen, the sandbox account would then be logged into (while the sandbox business account is logged in as well..they never explain why this must be the case) at this point the user should be prompted to enter credit card information, review the selected plan and then submit but I was never able to get past a single cryptic message. Posts to the Paypal developer forums went unheeded by the paypal developers who seemed to be actively answering the questions of others. After 3 days of waiting for a reply I gave up on Paypal.
Enter Amazon
I had to take a few days off after wrestling with Paypal's draconian system and in that time looked into my other options. Amazon , I recalled at recently began offering payment services through their AWS (Amazon Web Services) program. I investigated their offerings and noticed that they did have "pay now" services but unlike Paypal , they didn't have a "subscription" service. Luckily , as explained in In this post my framework provides a more efficient and reliaable way for me to simulate subscriptions. I could simply manage the users account access and duration using my Flags' and use only the "pay now" buttons to allow users to switch between plans or extend service for existing plans at any time.
This way Users can build up credit for their selected service plan in the form of usage days and when desired extend or upgrade their plans. This provides a versatility that neither Paypal or Amazon provided. As I continued to look into implementing Amazon I was pleased to see that their documentation was just slightly better managed than Paypal's but there were still glaring ambiguities in some of the writings. As programmers you think that the importance of syntax and the precise use of words would be something that writers of technical documentation would pay attention to, but not all technical writers are technically minded. Some of the instructions ommitted critical steps that absent would cause transactions to fail, others were plain wrong , still others would use "should" when they really meant "must" as I road the coaster of implementing the Amazon payment services I corrected several document mistakes by pointing them out in threads on the developer central web site.
I had already completed the required code on my end of the interaction, basically , when a user selects a plan the information would be sent securely to Amazon which would display the plan options , allow the user to select their credit card options (or store one with Amazon for use) and then submit the request and then send the user back to my site to a designated return URL. The parameters of the url would indicate the status of the transaction and payment information for the plan selected by the user. All this worked fine when the interaction was NOT signed, Amazon allows transactions to be signed with an encryption signature value generated from the unique attributes sent with a pay request. My site would generate the signature and add it to the outgoing request, Amazon would verify the request came from me by inversing the signature operation with a secret key.
This would guarantee that the request came from my servers and was not tampered with after the code was generated. On Amazon's end , after the user transaction is completed Amazon would then sign the return parameters and add a signature to that affect for my servers to inverse and guarantee came from Amazon. This way the transaction is authenticated at both ends and guaranteed to not have a "man in the middle" changing values either to upgrade services or lower prices without authorization. Unfortunately , the signature verification was not working, I sent out several threads asking for help on the Amazon site and unlike Paypal received answers from Amazon programmers that helped me hone in on the proper solution.
The proper solution involved fixing several errors in the existing Amazon test code (at least they had test code) and adding a convenient method to the test code that does the signature verification (Amazon only provided numbered instructions for this previously, now they have actual working code they can provide to implementer) I finally got the transactions working perfectly, securely and with signed parameters. I must mention that like Paypal Amazon requires the use of a "sandbox" account for the business (a fake business) and a sandbox account for a fake client. These are used to simulate payments when testing the code but unlike Paypal they didn't require that I be logged in on the computer while testing the code from my commercial site (which was bizarre) this allowed me to proceed with testing without getting frustrated at all the logins I had to perform.
Now that the e-commerce enablement is complete I am ready to roll the code out to the production servers....well, almost...there is one feature I wanted to sneak in to the framework...I'll talk about that more in the next post... ;)
Comments