The chronicles of commerce enabling my startup continue, after wrestling with the draconian and Gordian loops that Paypal requires for developers to get their payment services working properly I did some more research on the subject and decided to go with Amazon payment services as an alternative. You'll recall I first mentioned my attack of this issue way back in April.
The main trouble I had with paypal revolved around the amazingly complex set of actions that must be performed to test code, the unreliability of their system (they just recently had a string of hiccups that led to possibly millions of dollars in lost revenue from their existing customers...good thing I was not up and running at the time. I battled those issues for just over a week after writing that post and then decided to just let it rest until either paypal's issues resolved and or I had a calm mind enough to work through the issues they presented. I decided to finish up everything else that I had waiting which involved finishing the pages for the consumer web site and other little tweaks. I have done that and now attack commerce enablement with aplomb using the Amazon API and noticed one issue immediately. Unlike Paypal's services which provided an option for subscription buttons , Amazon as yet does not support recurring payments. This would be a deal breaker if it were not for a cool aspect of the framework I've designed that the Consumer Site is built on.
A short run down of what needs to be done is as follows:
What is cool about the whole thing is I was able to use a powerful feature of my web framework to make the process trivial. Ideally, I would have wanted Amazon to provide a subscription button as opposed to a pay now button, a subscription button would allow me to have Amazon handle recurring payments but Amazon doesn't have a subscription service so I have to simulate it. If I was able to get paypal to work reliably they do have subscription services but it is simpler to use the buy now button and simply handle the term expiration on my end. I was able to implement this without any need for changes to any classes in the framework API.
Flags
One of the most important features to be added to my framework was a way to granulate the actions performed against several dimensions. Originally the framework was designed as the base for a content management system as the first application so I needed a way to trigger changes to content at specific times, dates, on specific object types (story,ad) or by specific categories. I decided the best way to do this in as fine grained way as possible was to create what I called a Flag in the API. Flags allow specification of the attributes mentioned above as independently defined attributes. Date, Time, Type, Type ID and even the order of an item in a list of items can be made into discrete objects. These Flags can then be associated with various object sets in the system to allow the ad hoc creation of complex selection behavior. I realized the power of this and made it agnostic of type across the frameworks base class for new types. I also added the ability to control the periodicity of a Flag , controlling when it is "fresh". For example, a Flag can be Fresh on Monday of every week for a 3 months or it can be Fresh between 2pm and 8pm of April of this year only. Controlling periodicity of a Flag allows it to be used to control the triggering of any action. This allows Flags to be created to discretize any instance of any object type (including other Flags!). Combined with the ability to store those Flags in a queue and act on the "fresh" state of the Flag I was able to delay any action for exection on any instance of any object type. This takes us back to our problem of needing to simulate subscriptions using a buy now button provided by Amazon payment services. In order to simulate subscription I would need a way first to time limit a users account access to the term duration of their selected service plan.
When I first designed the framework and the Flag object I wanted to allow a system wide ability to specify when a User could log in to the system, the perfect candidate to manage this was a Flag. A User account can be given what is called a Temporal Flag which manages when they can login, this allows the system to control precisely when certain Users can login. Allowing or preventing access to the system off hours if that is desired. It also allows me to simulate the subscriptions, by specifying a Flag that has its "fresh" interval varied with the term of the service plans selected by the User during purchase. Enabling this for the paying Users was trivial, I simply had to update the "switch.jsp" that handled the actual job of updating the service plan status of a User to provide a Flag to that User with the required term duration (one month,3 months,6 months, a year) thus once the date specified in the Users temporal Flag is reached their account will go under temporal restriction and they will be prevented from Logging in.
The next step involved redirecting the temporally restricted User to the service plan page, this required isolating a unique aspect of paying Users and using that to generate a redirection to the service plans page instead of to their default page selected after login. This required adding a 4 line conditional that checked the temporal Flag existence as well as if the User account had a service plan, if both are true the User is guaranteed to be a paying customer whose term has expired. This would then trigger redirection to the service plan page to allow the User to reactivate their plan.
The next step involves changes to the "switch.jsp" template, to allow it to create and or update Flags with the new terms and options selected and confirmed as paid for by Amazon. This template is managed in the framework itself so the change required no core API changes. A wrinkle to the implementation related to 8 plans that are Site manager Plans, these allow a User to manage their own Site full of their own Users, I needed to disable or enable these Users for the site...this didn't require any changes other than the necessary method calls in the clauses that invoked these plans. The changes would be made in real time to the Users account updating their current session object and allowing them to immediately continue their session!
I am partly through the implemention of stage 3 above, having started the Flag insert /update code which I will finish tomorrow. I am so happy I added Flags to the framework...what could have been weeks of work should be wrapped up in little more than two days.
The main trouble I had with paypal revolved around the amazingly complex set of actions that must be performed to test code, the unreliability of their system (they just recently had a string of hiccups that led to possibly millions of dollars in lost revenue from their existing customers...good thing I was not up and running at the time. I battled those issues for just over a week after writing that post and then decided to just let it rest until either paypal's issues resolved and or I had a calm mind enough to work through the issues they presented. I decided to finish up everything else that I had waiting which involved finishing the pages for the consumer web site and other little tweaks. I have done that and now attack commerce enablement with aplomb using the Amazon API and noticed one issue immediately. Unlike Paypal's services which provided an option for subscription buttons , Amazon as yet does not support recurring payments. This would be a deal breaker if it were not for a cool aspect of the framework I've designed that the Consumer Site is built on.
A short run down of what needs to be done is as follows:
- Paying customer with an existing account with a specific term of service (say 3 months) expires between logins.
- On next login customer should be redirected to service plan upgrade page to extend the terms of their service on their existing account.
- After selecting a new plan and term and submitting request using Amazon button, the User should be prompted to pay using Amazon payment service and then redirected back to consumer site.
- My site should confirm the request payment and on that basis do the switch to the new plan or reenable the existing plan and send off a notification email as receipt.
What is cool about the whole thing is I was able to use a powerful feature of my web framework to make the process trivial. Ideally, I would have wanted Amazon to provide a subscription button as opposed to a pay now button, a subscription button would allow me to have Amazon handle recurring payments but Amazon doesn't have a subscription service so I have to simulate it. If I was able to get paypal to work reliably they do have subscription services but it is simpler to use the buy now button and simply handle the term expiration on my end. I was able to implement this without any need for changes to any classes in the framework API.
Flags
One of the most important features to be added to my framework was a way to granulate the actions performed against several dimensions. Originally the framework was designed as the base for a content management system as the first application so I needed a way to trigger changes to content at specific times, dates, on specific object types (story,ad) or by specific categories. I decided the best way to do this in as fine grained way as possible was to create what I called a Flag in the API. Flags allow specification of the attributes mentioned above as independently defined attributes. Date, Time, Type, Type ID and even the order of an item in a list of items can be made into discrete objects. These Flags can then be associated with various object sets in the system to allow the ad hoc creation of complex selection behavior. I realized the power of this and made it agnostic of type across the frameworks base class for new types. I also added the ability to control the periodicity of a Flag , controlling when it is "fresh". For example, a Flag can be Fresh on Monday of every week for a 3 months or it can be Fresh between 2pm and 8pm of April of this year only. Controlling periodicity of a Flag allows it to be used to control the triggering of any action. This allows Flags to be created to discretize any instance of any object type (including other Flags!). Combined with the ability to store those Flags in a queue and act on the "fresh" state of the Flag I was able to delay any action for exection on any instance of any object type. This takes us back to our problem of needing to simulate subscriptions using a buy now button provided by Amazon payment services. In order to simulate subscription I would need a way first to time limit a users account access to the term duration of their selected service plan.
When I first designed the framework and the Flag object I wanted to allow a system wide ability to specify when a User could log in to the system, the perfect candidate to manage this was a Flag. A User account can be given what is called a Temporal Flag which manages when they can login, this allows the system to control precisely when certain Users can login. Allowing or preventing access to the system off hours if that is desired. It also allows me to simulate the subscriptions, by specifying a Flag that has its "fresh" interval varied with the term of the service plans selected by the User during purchase. Enabling this for the paying Users was trivial, I simply had to update the "switch.jsp" that handled the actual job of updating the service plan status of a User to provide a Flag to that User with the required term duration (one month,3 months,6 months, a year) thus once the date specified in the Users temporal Flag is reached their account will go under temporal restriction and they will be prevented from Logging in.
The next step involved redirecting the temporally restricted User to the service plan page, this required isolating a unique aspect of paying Users and using that to generate a redirection to the service plans page instead of to their default page selected after login. This required adding a 4 line conditional that checked the temporal Flag existence as well as if the User account had a service plan, if both are true the User is guaranteed to be a paying customer whose term has expired. This would then trigger redirection to the service plan page to allow the User to reactivate their plan.
The next step involves changes to the "switch.jsp" template, to allow it to create and or update Flags with the new terms and options selected and confirmed as paid for by Amazon. This template is managed in the framework itself so the change required no core API changes. A wrinkle to the implementation related to 8 plans that are Site manager Plans, these allow a User to manage their own Site full of their own Users, I needed to disable or enable these Users for the site...this didn't require any changes other than the necessary method calls in the clauses that invoked these plans. The changes would be made in real time to the Users account updating their current session object and allowing them to immediately continue their session!
I am partly through the implemention of stage 3 above, having started the Flag insert /update code which I will finish tomorrow. I am so happy I added Flags to the framework...what could have been weeks of work should be wrapped up in little more than two days.
Comments