Mobile App integration

VERY IMPORTANT: Before you start integrating this flow, make sure, you have read the the Introduction and Licenses and Interfaces chapters. They contain general and vital information, not only about the JSON-API, but also for you, the merchant! Furthermore, also make make sure, whether, or not PSD2 does apply to you!

Payments done via a smartphone through a mobile app, are becoming more and more important. Saferpay offers the tools needed to be integrated via a mobile app. The following guide is an extension, to the standard integration methods for the Transaction interface and Secure Alias Store.

The Integration centers around a client-server model (the app being the client), in which a merchant server hosts all the necessary data, to do the requests itself and store any vital data, the app and therefore the customer/card holder, does not need to know.

Process

The general process is as follows:

alt text

  1. The app calls the server to make a payment.
  2. The Server calls Saferpay, doing either a, Transaction Initialize, or Alias Insert.
  3. Saferpay responds with a Token and the RedirectUrl.
  4. The server saves the Token and forwards the RedirectUrl to the app.
  5. The app opens up a native card-form.
  6. The card holder enters his card details and submits the form.
  7. The card details are posted to saferpay directly, using the RedirectUrl as the endpoint.
  8. Saferpay responds with a new RedirectUrl for 3D Secure and DCC, if applicable.
  9. The App either opens the Url inside a Webview, or opens the phone browser.
  10. The user may authenticate him/herself through 3DS and perform DCC.
  11. Once the external process is completed, the card holder gets redirected to the ReturnUrls
  12. The App intercepts the Redirect, through the Webview-handler
  13. The app instead opens up the In-App return-page, while asking the server for the final outcome.
  14. The Server executes the Authorization and forwards the result to the app.
  15. The app confirms the recipience, so the server may finalize and capture the payment, while the app either displays a success, or a failure.

Request and response of Card-Post

Request

The following parameters need to be posted from the app to the RedirectUrl (See step 7):

Parameter Type Usage Description
RedirectUrl URL M The RedirectUrl will be the endpoint, the card details are posted to!
HolderName String M Input for the card-holder name.
CardNumber String M Input for the card-number (PAN).
ExpMonth String M Input for the expiration-month.
ExpYear String M Input for the expiration-year.
VerificationCode String M Input for the Card Verification Code (CVC).
FromAjax Boolean O Must be set to "true", in order to recieve a JSON-response!

Response

The Response will be a JSON-Object.

Success-Response in case of an http-200 response:

Parameter Type Usage Description
RedirectUrl URL mandatory RedirectUrl to open up inside a webview!

Error-Response in case of an http-4xx response:

Parameter Type Usage Description
ErrorName String mandatory Description, or ID of the error
Behavior String mandatory Further details on how to proceed (RETRY_LATER, RETRY, ABORT...).
ErrorDetail String optional Further details on the error itself, if available. For example, if the ErrorName=VALIDATION_FAILED, the ErrorDetail contains a list of the invalid input-fields (“CardNumber”, “ExpYear”, “Ex-pMonth”, etc.)
Back to Top