Skip to main content

commerce enable redux

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:

  1. Paying customer with an existing account with a specific term of service (say 3 months) expires between logins.
  2. On next login customer should be redirected to service plan upgrade page to extend the terms of their service on their existing account.
  3. 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.
  4. 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

Popular posts from this blog

Highly targeted Cpg vaccine immunotherapy for a range of cancer

Significance?


This will surely go down as a seminal advance in cancer therapy. It reads like magic:

So this new approach looks for the specific proteins that are associated with a given tumors resistance to attack by the body's T cells, it then adjusts those T cells to be hyper sensitive to the specific oncogenic proteins targeted. These cells become essentially The Terminator​ T cells in the specific tumor AND have the multiplied effect of traveling along the immune pathway of spreading that the cancer many have metastasized. This is huge squared because it means you can essentially use targeting one tumor to identify and eliminate distal tumors that you many not even realize exist.

This allows the therapy for treating cancer to, for the first time; end the "wack a mole" problem that has frustrated traditional shot gun methods of treatment involving radiation and chemotherapy ...which by their nature unfortunately damage parts of the body that are not cancer laden but …

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…

AgilEntity Architecture: Action Oriented Workflow

Permissions, fine grained versus management headache
The usual method for determining which users can perform a given function on a given object in a managed system, employs providing those Users with specific access rights via the use of permissions. Often these permissions are also able to be granted to collections called Groups, to which Users are added. The combination of Permissions and Groups provides the ability to provide as atomic a dissemination of rights across the User space as possible. However, this granularity comes at the price of reduced efficiency for managing the created permissions and more importantly the Groups that collect Users designated to perform sets of actions. Essentially the Groups serve as access control lists in many systems, which for the variable and often changing environment of business applications means a need to constantly update the ACL’s (groups) in order to add or remove individuals based on their ability to perform certain actions. Also, the…