Rethinking the SkySales Payment Control

The Navitaire New Skies SkySales web platform ships with a number of controls out of the box. One of the more complicated of these is the PaymentInput control.

The PaymentInput control was created with a tabbed paradigm in mind:

Figure 1 - CebuPacific’s Default PaymentInput Control

The original idea was that since the customer could have multiple forms of payment available to them (vouchers, credit, credit cards, etc) and they could pick and choose between adding types of payment by clicking on tabs to enter into the specific payment mode. The concept probably sounded great because the forms of payment are dynamic, so it’s easy to add and remove tabs based on what the customer has available to them. In practice, airline websites just don’t work that way.

The major problem with the default payment control is that it’s bound by the ASP.NET postback model. A postback to the server is required to change payment modes and to change credit card types. Both of these are confusing to a customer and cause discomfort and discord at the moment of sale.

A secondary problem is that since the control is attempting to handle all forms of payments, it’s output and structure is a mess. It’s complicated enough as is, but to customize it quickly becomes a bigger mess. After seeing a competent team’s attempt at customizing the base payment control and seeing the spaghetti code created to coax the control to add simple business functionality, I decided that it needed to ultimately be deconstructed and rebuilt from the ground up.

The following diagram shows the before and after structure of the payment control:

Figure 2 - Before Refactoring

And now after we refactored the code into nice specific chunks:

Figure 3 - After Refactoring

The new payment control set follows basic object orientated principals by having an abstract base control that contains common functionality needed by most controls and the concrete implementations of the different forms of payment are left to specific payment classes.

This structure is now easy to understand with events and well-defined points of integration.  If a carrier decided to accept an alternate form of payment like PayPal, they would simply need to create a new simple concrete class that collects the payment information, creates the appropriate payment class and submits the payment.

Another feature of having independent payment classes is that they can co-exist on a payment page together. Remember, with the default Navitaire payment control you had to be in a certain payment mode. You can’t have vouchers and credit cards both ready to be utilized on the same page at the same time with out getting your hands messy in the default control.

The last benefit of this refactored control is in the realm of refunds. Without carefully configured rules, it may be possible to use the payment page in the booking path as a way to get refunds in certain circumstances. Having explicit forms of payment defined on that page prevents those scenarios.

That’s it! By implementing your own custom payment control you can easily control your own destiny with one of the most critical parts of the booking process: the cash register.

If you’re interested in the production code that goes along with this article, please contact me.