After the Swipe: Transaction Management

There is a perception – perhaps even a misconception – among those looking to do a payments integration, that completion of the project should be something like one of the following use cases:

• Add a field that reads from a USB swipe control, and a submit button.
• Add a text entry field, a card-type drop-down, maybe something for those 3 digits on a card, and a submit button.

The availability of APIs for commerce integrations has begun to drastically decrease the time required to complete an integration…but the process of adding payments to software is somewhat more complex than a text entry field and a submit button.

One thing that is frequently overlooked during the initial scoping exercise is transaction management.

What happens after a transaction has been settled?
How will the application handle refunds of transactions?
How will the application handle voids of transactions?
How will reporting, both post and pre-settlement, be handled?

These workflows, a requirement by the merchant customer using the application, represent additional development, testing, and integration work for the Software Company or developer. In the case of an eCommerce integration, this typically encompasses more development resources, time, and knowledge than the process of building the initial page for payment acceptance.

How can this issue of time and expertise be addressed?

One of the important capabilities of the IP Commerce Platform is the ability for Software Companies to build workflow and solutions that are valuable to other Software Companies. We refer to these “snap-in business solutions” as Commerce Modules. I will write more, tomorrow, about the technical side of this integration…but, for now, suffice it to say that the experience is seamless from both the perspective of branding & credentials.

There is none who are better suited to solve the pain of a Software Company than other Software Companies.

Introducing the Transaction Management Commerce Module.

Transaction Management, as a Commerce Module, solves for the post-settlement refunds, pre-settlement voids, searching and reporting on transaction information, as well as real-time transaction status and payment details. As a solution, it is hosted in a PCI compliant data center thereby ensuring the implementation does not introduce additional risk to the merchant customer. This specific module was built by aurionPro and leverages their expertise in the Banking & Payments technology sectors.

As you would imagine, there are several targeted business solutions that IP Commerce has identified as potential Commerce Modules based upon our experience with the development community. I, personally, am excited to see what other Commerce Modules the Software community creates to solve for each others pain.

Payment application development is quite interesting…opening APIs for commerce development is compelling…pairing these with a powerful Platform to drive innovation is exciting…enabling Software Companies to build solutions that solve the pain of other Software Companies — that is unique and powerful.

What’s your perspective? Agree? Disagree? Anything to add? Critiques? The comment form is below…

July 27, 2010

Posted in IP Commerce, Software Companies and tagged Modules.