Paythru's API's are currently designed to be used during web-based user journeys, but it is possible to make them work for in-app use. This documentation aims to provide an overview of the interactions required to make this work.
This document assumes that you would use the Client POST API to collect cards from customers, the Gateway API to process the transactions and the Tokenisation API to store cards for future use.
This integration method relies on server-to-server calls for carrying sensitive credentials. You will require a mechanism to authenticate genuine requests from your app to you own server, this is outside of the scope for this document.
2.0 Integration overview¶
2.1 Integration breakdown¶
At the point you need to collect payment card information from a consumer, take the following actions:
- Your app first makes a call to your own server, via an appropriate authentication mechanism. The authentication mechanism used between your app and your server is outside of the scope of this document, but the authentication provided by our payment API's is not suitable for use directly from a mobile application.
- You server, having authenticated the call from the app, calls the Client POST API
/v3/session/initiatemethod to get back a
sessionKey, which it provides back to the app.
- The app presents a payment form to the customer and submits the results directly to the Client POST API
/v3/session/postformmethod using the
sessionKeyobtained via the call to your server. By sending the card data directly your app is processing cardholder data and would need to be compliant with (at least) requirement 6 of the PCI standards, but your server will not be processing, storing or transmitting cardholder data and so could remain out of scope for PCI or SAQ A eligible.
- The Client POST API
/v3/session/postform/ajaxpostmethod will respond with a
Locationhttp header to issue a redirect command. Your app must intercept this redirect, inspect the
Locationheader and check the value within. It will either be the
errorPageUrlfrom your Client POST API
/v3/session/initiatecall or one of the
currentPageUrlvalues from your Client POST API
/v3/session/postformcall in the previous step. Use this to route your logic to an error message or onto the next step.
postformmethod responds with encrypted information in the querystring of the
Locationhttp header (the
dataparameter). This information will need to be decrypted on your own server to establish whether the
postformsubmission was accepted successfully or whether there were errors. See "Handling Post Form Response" on the Client POST API for more detail.
- If the redirect takes you to the value supplied as your
currentPageUrlthen the payment card details were successfully stored in the session, you can now issue a server-to-server call to the appropriate Gateway API method (
/v3/transaction/initiate3DSecureSessionKey) to process a payment.
- If you also want to tokenise the card for future re-use you can call the Tokenisation API
/v3/token/tokeniseTransactionKeymethod with the