Click here to Skip to main content
Click here to Skip to main content
Go to top

A Simple Gateway - Proxy Pattern

, 12 Aug 2013
Rate this:
Please Sign up or sign in to vote.
An example of a simple payment gateway.

Introduction

Here’s an approach I've used a few times to consume similar APIs into an application. A gateway of sorts, if you will. I'll try and keep it as brief and simple as possible. Having a look at the sample code will help you along as well. I also assume that you know something about Reflection and Web services.

Why would you implement such a thing?

Well (hypothetically, of course), imagine you get a third party payment solution that only accepts Visa cards. OK, you've implemented the Visa payment provider. Now, some of your customers would want to pay with MasterCard. And, you'd suspect that someone down the track would like to use Amex as well.

You would be able to add every payment provider into your code as you need, but this will get messy very quickly. Whereas, loosely coupled API wrappers (proxy wrappers, in this example) in a “gateway” will allow you to add and remove payment providers as you please. Even add some business logic that will decide which provider is the cheapest for your users... So, if you'd implemented a “gateway” from the start, adding new payment providers through the duration of your application life is a breeze, well, a lot easier and cleaner at least.

Here’s a quick example of creating an API gateway. I've used two web services in this example, but libraries can be plugged-in in a similar way.

Design

Looking at the image above, I'll briefly go though the entities of the solution. I'll be focusing mainly on the Gateway and API 1 and 2 entities.

  • Solution: This would typically be your application's business logic.
  • Gateway: The connection between your application and the API wrappers.
  • API 1 & 2: These are the wrappers around API Proxy 1 & 2.
  • API Proxy: These represent our payment gateway providers. These are the services that we will consume.

The gateway

I am going to go through the gateway first and then the API wrappers, and after that, I'll explain how it all hooks up.

The interface is the part that really gets the gateway together. As shown in the image above, the Gateway and API wrappers both implement the interface. So, let's whack one together.

In my example, I created IGateway:

public interface IGateway
{
   bool ValidateUser(Userobj user);
   string GetUserAddress(Userobj user);
}

I'm using Reflection in the gateway to call the API wrappers. By implementing an interface, we'd know exactly what method to call, parameters to pass down, and what to expect in return.

In this example, I want to validate a user and get his address. Now that we have defined what we need, we can define our interface. Let's add it to the gateway.

public class Gateway: IGateway
{
    IGateway proxy;

    public Gateway(String dllNamePath)
    {
       LoadIGhostAssembly(dllNamePath);
    }

    void LoadIGhostAssembly(String dllNamePath)
    {
       Assembly asm = Assembly.LoadFrom(dllNamePath);
       Type[] typesInAssembly = asm.GetTypes();

       foreach(Type t in typesInAssembly)
       {
          if (t.GetInterface(typeof(IGateway).FullName) != null) 
          {
             proxy = (IGateway)Activator.CreateInstance(t);
          }                       
       }
    }
        
    //IGateway Members
    public bool ValidateUser(Userobj user)
    {
       return proxy.ValidateUser(user);
    }

    public string GetUserAddress(Userobj user)
    {
       try
       {
          return proxy.GetUserAddress(user);
       }
       catch { return "Facility doesn't exist"; }            
             
    }
}

LoadIGhostAssembly is where we get the correct API wrapper to call. My business logic will pass down the Visa or Mastercard library location, depending on which one you want to use. As shown in the diagram above, the API wrappers also implement the IGhost interface. We will instantiate the correct reference and create a direct mapping to the API wrapper's interface methods.

The API wrappers

I've created a new library and added a class that implements my interface. Now, I will consume my desired web service (called WebServiceMasterCard and WebServiceVisa in the sample code), and match it to my interface methods.

public class Proxy : Global.IGateway
{
   #region IGateway Members

   public bool ValidateUser(Global.Userobj user)
   {
      try
      {
      ProxyWebServiceVisa.localhost.Service1 apiProxy = 
        new ProxyWebServiceVisa.localhost.Service1();

         return apiProxy.CheckUser(user.UserID);
      }
      catch { return false; }
   }

   public string GetUserAddress(Global.Userobj user)
   {
      ProxyWebServiceVisa.localhost.Service1 apiProxy = 
        new ProxyWebServiceVisa.localhost.Service1();

      return apiProxy.UserAddress(user.UserID, user.FirstName, user.LastName);
   }

   #endregion
}

Repeat this for every payment provider you want to add to your gateway.

The glue

simplegateway/gatewaysolution.jpg

This is how I would call the gateway from my application:

UserGateway.Gateway gateway = 
    new UserGateway.Gateway("c:\\temp\\ProxyWebServiceMasterCard.dll");

gateway.ValidateUser(user)
gateway.GetUserAddress(user)

As you can see, I call the gateway and pass down the desired service I need. As long as all the API wrappers have implemented the proper interface, you can add as many as you wish, even take some out. I hardcoded the location of the library, but I usually add it to an XML, database or common directory, so the code wouldn't need to be recompiled every time I need to add a service to the gateway. Once you've specified the library you want to use, the gateway will create an instance of it by using Reflection, and with the method mapping, you can call any method you desire.

And presto, create as many API wrappers as you wish, as long as they implement your interface and your gateway will recognise them.

Update: This is also an example of the Proxy Pattern implementation, which I unknowingly implemented at the time of conception. Please look at Proxy Patterns for more details.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Johan Vorster
Software Developer
United Kingdom United Kingdom
No Biography provided

Comments and Discussions

 
Question[My vote of 1] Almost not even an article Pinprofessionaljfriedman17-Jan-14 14:35 
GeneralMy vote of 5 PinmentorMd. Marufuzzaman22-Dec-12 23:27 
GeneralMy vote of 5 PinmvpKanasz Robert28-Sep-12 7:12 
QuestionMIGS Implementation PinmemberDinoDonk11-Jan-10 0:43 
QuestionPayment Providers and Gateway API Pinmemberstixoffire22-Dec-08 21:41 
AnswerRe: Payment Providers and Gateway API PinmemberJohan "BJ" Vorster22-Dec-08 23:09 
GeneralI liked the idea PinmemberMember 441105731-Oct-08 13:58 
JokeRe: I liked the idea PinmemberJohan "BJ" Vorster2-Nov-08 1:42 
GeneralRe: I liked the idea Pinmemberyasmin8316-Nov-08 1:08 
GeneralRe: I liked the idea PinmemberJohan "BJ" Vorster17-Nov-08 3:19 
GeneralRe: I liked the idea Pinmembersj17118-Jun-09 22:09 
GeneralRe: I liked the idea PinmemberJohan "BJ" Vorster19-Jun-09 0:28 
QuestionOnline payment - MIGS PinmemberBlumen27-Oct-08 21:25 
AnswerRe: Online payment - MIGS PinmemberXabatcha28-Oct-08 1:52 
GeneralRe: Online payment - MIGS PinmemberBlumen28-Oct-08 3:14 
AnswerRe: Online payment - MIGS PinmemberJohan "BJ" Vorster28-Oct-08 2:05 
GeneralRe: Online payment - MIGS PinmemberBlumen28-Oct-08 3:23 
GeneralRe: Online payment - MIGS PinmemberJohan "BJ" Vorster28-Oct-08 4:12 
Enjoy the hot weather Manu!! It's cold here!
 
Are you targeting local users or international clientèle?
 
Rather then searching for MiGS, search for "payment solutions" or "online payment solutions providers". There's the usual suspects, Pay Pal, Google Checkout, and so forth. but it's up to you to find the one that is "tailor made" for you application.
 
A payment provider should just slot into your website or application. You shouldn't design around the payment providers API. Hence your own payment gateway. But you would have to identify what you'll need from a payment provider and implement that into your gateway. Eg. createNewAccount(), updateAccountDetails(), updateCardDetails(), getBillingHistory(), tenderAmount(). Just to name a few. Or maybe that's all you need.
 
Complex, well it'll only be as complex as you make it. But try and keep it simple, simple is actually an art form in this industry. Simple goes along way.
 
Shopping card, well I have never created one before, but what I have seen is that developers persist the information in either cookies or session object, so you won't need to save and recall that sort of info from the db. But then again you might want to track trends for your marketers, then you'll have to save it.
 
Sounds like an interesting journey for you ahead. If I had to say one thing, it'll be better if you start the project from scratch rather then using a web framework. Unless it's Django...
 
Distribution logistics? Have you thought about delivery service for your solution?
 
The two areas I'd focus on first is the user and the product information and how that is stored and related to each other. Payment is almost a by product of these two areas.
 
Laters
Johan
GeneralRe: Online payment - MIGS PinmemberBlumen28-Oct-08 19:58 
AnswerRe: Online payment - MIGS PinmemberJohan "BJ" Vorster29-Oct-08 0:09 
GeneralRe: Online payment - MIGS PinmemberBlumen29-Oct-08 2:38 
GeneralRe: Online payment - MIGS PinmemberJohan "BJ" Vorster29-Oct-08 3:34 
GeneralRe: Online payment - MIGS PinmemberBlumen29-Oct-08 18:05 
GeneralRe: Online payment - MIGS PinmemberBlumen1-Nov-08 3:43 
GeneralRe: Online payment - MIGS PinmemberJohan "BJ" Vorster2-Nov-08 2:10 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.140926.1 | Last Updated 12 Aug 2013
Article Copyright 2008 by Johan Vorster
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid