Working with Spire and Ingenico

One of our team's most recent pieces of work has been integrating payment devices into kiosk solutions for a client.

The business of taking a payment from a card and pin involves a web of different providers extending out from the banking system. Our role is to pick up the transaction and integrate it with a business process. This involves our business workflows interacting with a payment device as a device goes through a process of:-

1. Verify the Card
2. Verify pin
3. Commit transaction and verify funds with the primary acquirer

The primary acquirer is the next layer into the banking system managing the transaction.

We have been working with two self service payment devices; the Spire Modular and the Ingenico's iSelf IUP250. We created software wrappers for both of these physical devices, exposing their core functionality to our clients' business workflows. We have integrated both devices (as different end users have relationships with the different equipment suppliers and their partners) and our solution makes the devices interchangeable. Below, Lee, who worked on this, outlines some of the issues.

Integrating with SPIRE

With the Spire device we receive access to a 'static C library'; a programming interface we can address using unmanaged code. However as a business software developer we normally choose to work in managed code -- this means that our developers spend their time thinking about the business rules we are building into the software, and not internal computer memory structure, allocation, etc.

So, we needed to create a wrapper around the Spire library that allowed it to be integrated with managed code on a Windows system. We tackled this by writing some unmanaged C++ code and pulling it into a wrapper that managed code could read. From there, we could pull the functionality into our normal development environment. There were a few tricky 'gotchas' on the way; capturing events such as payment failures, and allowing the software to decide how to respond.

Integrating with Ingenico

For working with the Ingenico devices we started somewhat further down the path: for the relevant 'Primary acquirer' (Credit Call) the device came with a managed code library we could work with. If this was not the case it would be a matter of rolling up our sleeves and tooling up to programme on Ingenico’s Telium platform. The developers would love to do this, however there has to be a pressing need for such expense.

Getting Help Pulling it Together

Key to pulling all of the elements together, in a standard platform, alongside smartcard and other elements of the final solution, is having someone to talk to. When needed, we have been able to get on the phone for a bit of support for our development process. Hemisphere West, who were the supplier of the equipment, were helpfully able to answer or signpost us to the right source of information. We also spent some time on the phone to Credit Call for the Ingenico interface, and Spire for building the wrapper around their system. It takes a string of relationships to pull these systems together and some project management persistence.

We Can Do It

If you're interested in applying Village Software's expertise and tenacity to your business situation, then drop us a line! We're thinkingahead@villagesoftware.co.uk