You are going to implement a payment connector. You know everything about the new payment API because you have read the cookbook and closed your SPIKEs (which means that you are 10% ready).
But now you have to make some irritating decisions. You have to decide how to establish a connection with your payment service provider (PSP). The PSP-s usually provide various options:
- RESTful interface
- XML-RPC
- SOAP
- SDK-s
SDK-s are a bunch of classes which provide “convenient” wrappers and hide all communication details which you will otherwise have to tackle. Usually they are available as libraries for different languages. E.g. Java, PHP, Python, ASP, etc.So I guess you will immediately make a fast decision to use an SDK instead of plain REST, for example. Life will be easier, won’t it? Not necessarily. I’ll try to describe some drawbacks of both approaches. I have experienced these drawbacks in escallations, payment connector migrations and new development.
Drawbacks of using SDK-s
SDK-s:
- evolve and should be migrated themselves. This is a continuous effort and should be acknowledged;
- contain bugs. If you hit a bug there is usually not much that you can do especially if the SDK is not open source. And it is very unpleasant if this bug arrives at your table wrapped as an escalation for your own connector;
- communication details are hidden and inaccessible. Sometimes this may be painful. For example PayPal migrated to TLSv1.2 and we had to fix an old version of the connector which used an SDK powered by Axis 1. Do you think it is fun to configure Axis 1 to support TLSv.1.2? No… it may not be that funny;
- depend on other commonly used libs. These libs are also used by our core product and sometimes the versions of the dependencies of the SDK and our product may collide. Then you have a HUGE problem. And your migration efforts may sky-rocket.
- SDK-s may evolve slower than the REST interface. For example, I’ve seen a project that needed a feature available in the RESTful interface but still not available in the SDK;
- You may need to handle some very low-level details (e.g. proxy connectivity) that may be difficult or impossible via an SDK;
- SDK-s have a learning curve themselves;
Drawbacks of using raw protocols
Raw protocols:
- are not always REST. How about XML-RPC?
- require care about many low level details (e.g. OAuth, performance issues, adding partner ID-s in the headers, retries, error handling, etc). Summing all this the networking part may become challenging!
- require using other libraries – e.g. JAX-RS/Jersey+Jackson for consuming RESTful interfaces (follow my older posts in order to discover some of the challenges);
- require additional classes – e.g. POJO-s used for data transfer, JAXB classes, etc.
- cause additional bugs in our connectors;
So which approach to use? No idea. Depends on the PSP, on what they recommend, on your 6-th feeling, on your luck and heritage… I’ve used both and both will bring different set of problems in your daily agenda. 