Business and Technical Decisions
Supporting a new Platform within the Cashier requires the Platform have an API exposing the necessary web services to be consumed by the Cashier. During the development phase of the Platform’s web service, we normally recommend that this is handled over the Internet as it allows for faster iterations between your Platform team and our Cashier team. Once this testing phase is complete, we can proceed to install the Cashier into your computing environment and run more tests as API integration is essentially complete. This would typically be an internal LAN communication between the Cashier and your Platform, offering the benefits of a faster, more secure, direct connection between both applications.
To implement your API web service, you can choose your coding language of preference as long as you support HTTPS POST and are web friendly. You also have your choice of the request/response of your web service between: raw HTTP Post, JSON, XML or SOAP XML, etc. We do not recommend using RESTful HTTP status codes but instead return an HTTP 200 OK status when your web service was able to accept and process the request, and if any application errors occurred, then return those details in the web service response body in your chosen format (e.g. serialized response either querystring, XML or JSON). If possible your API should always return an accurate reason for any service method failure, which facilitates troubleshooting issues in production to the business operators.
You are currently viewing version 2.24b Latest version here