LogoLogo
BlogLogin
English
English
  • An Introduction to Saferpay
    • Licensing
      • Legacy licensing
    • Reconciliation
    • Acquirers & Payment Methods
    • Web Shop Plugins and certified partners
      • ePages Beyond
      • ePages NOW
      • Magento 2
      • Odoo
      • PrestaShop
        • PrestaShop User Guide
      • Salesforce Commerce Cloud
      • SAP Commerce Cloud
      • Shopware 6
        • Shopware 6 User Guide - German
        • Shopware 6 User Guide - English
      • WordPress WooCommerce
      • Shopify
    • Supported Languages
    • Common Saferpay terms - Glossary
  • News
    • Changes for transactions without customer presence
    • Changes for the Saferpay Hosted Forms, Fields and Payment Page
  • Quick Links
    • Web Shop Plugins and certified partners
    • Secure PayGate
    • User Administration
    • Payment Page Configuration
    • Risk Management
    • API Authentication
  • Interfaces
    • Payment API (aka JSON API)
    • Management API
    • Backoffice
      • The Home screen
      • Batch Processing
      • Transactions
        • Transaction Details
        • Batch Close
        • Declined transactions
        • Pending authorizations
        • Analytics
        • SEPA Refunds Export
        • Authorization & Payment
        • Credit
      • Risk Management
      • Secure PayGate / Payment Links
      • Secure Card Data
        • Secure Card Data Details
      • Settings
        • JSON API basic/Client Certificate authentication
        • User Administration
        • Payment Page Configuration
      • Online Support
      • User Profile
    • Saferpay OnSite
    • Feedback
  • Integration Guide
    • Integrating Saferpay
    • General Information
      • Data Security and PCI DSS
      • Versioning
      • 3-D Secure
      • Payment Service Directive 2 - PSD2
      • Dynamic Currency Conversion
      • Iframe Integration and CSS
    • Ways of integration
      • Payment Page
        • Payment Page checklist
      • Transaction Interface
        • Recurring Payments
        • Refunds
          • SEPA Refunds
      • Capture and Daily Closing
        • Partial Captures
          • Marketplace
      • Secure Card Data - Tokenization
      • Saferpay Fields
      • Inquire Interfaces
      • Mobile Integration
      • Omni-Channel
      • Fraud Intelligence
        • Silver
        • Fraud Intelligence Integration
      • Mail Phone Order
      • Error Handling
      • API Health Check
      • Saferpay API Specification
    • Payment Methods & Wallets
      • General and special cases
      • Account-to-Account Payments
      • Alipay+
      • Apple Pay
      • American Express
      • Bancontact
      • Billie
      • blik
      • Click to Pay
      • Diners Club International & Discover Card
      • eps
      • giropay
      • Google Pay
      • iDEAL 2.0
      • JCB
      • Klarna Payments
      • Maestro International
      • Mastercard
      • paydirekt
      • PayPal
      • PostFinance Pay
      • Przelewy24
      • Reka
      • SEPA Direct Debit
      • Sofort by Klarna
      • TWINT
      • UnionPay
      • Visa & V PAY
      • WeChat Pay
      • WL Crypto Payments
    • Testing
    • Go-Live
    • Frequently Asked Questions
    • Saferpay Demo
      • Saferpay Demo Environment
      • Saferpay Demo Shop
    • Support
    • Changelog
Powered by GitBook
On this page
  • Credit Card Process
  • Request and response of a Card-Post
  • 3rd Party Payment Methods

Was this helpful?

  1. Integration Guide
  2. Ways of integration

Mobile Integration

PreviousInquire InterfacesNextOmni-Channel

Last updated 11 months ago

Was this helpful?

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

Credit Card Process

General process:

  1. The app sends a message to your backend server to make a payment.

  2. Saferpay responds with a token and the RedirectUrl.

  3. The server saves the token and forwards the RedirectUrl to the app.

  4. The app opens up a native card form.

  5. The card holder enters his card details and submits the form.

  6. The card details are posted to Saferpay directly, using the RedirectUrl as the endpoint.

  7. Saferpay responds with a new RedirectUrl for 3D Secure and DCC, if applicable.

  8. The app either opens the Url inside a WebView, or by using the phone's browser.

  9. The user may authenticate him-/herself through 3DS and perform DCC.

  10. Once the external process is completed, the card holder gets redirected to the ReturnUrl.Url

  11. The app intercepts the redirect through a WebView-handler

  12. The app opens up the in-app return page instead, while asking the server for the final outcome.

Do not implement calls to Saferpay directly in your app! While technically possible, this would mean that you'd store the authentication credentials (user name and password, or certificate) in the app itself. Those credentials can be extracted and then used for mailicious actions on your account. ALWAYS implement the server-client model described above.

Note, that this example assumes a native in-app card form.

Hosting a native form on your own server and displaying said form in a web-view, or browser and/or posting the card-data anywhere else, but Saferpay directly -e.g. first to your server and then to Saferpay-, falls under PCI and needs special certification.

Request and response of a Card-Post

Request

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

Parameter

Type

Usage

Description

RedirectUrl

URL

mandatory

Endpoint where the card details are posted to

HolderName

String

mandatory

Card holder name

CardNumber

String

mandatory

Card number (PAN)

ExpMonth

String

mandatory

Expiration month

ExpYear

String

mandatory

Expiration year

VerificationCode

String

mandatory

Card Verification Code (CVC)

FromAjax

Boolean

optional

Must be set to "true" in order to receive 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

Url 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, if available. For example, if the ErrorName=VALIDATION_FAILED, the ErrorDetail contains a list of the invalid input-fields (“CardNumber”, “ExpYear”, “ExpMonth”, etc.)

You do not need to re-initialize the API, if you get an error-response (Like invalid card details etc.). You can re-use and perform multiple POST-requests towards one RedirectUrl multiple times.

This saves on requests and also avoids unwanted behavior, especially in cases, where the connection is lost during re-initialization.

3rd Party Payment Methods

3rd party payment methods process:

  1. The app sends a message to your backend server to make a payment.

  2. Saferpay responds with a token and the RedirectUrl.

  3. The server saves the token and forwards the RedirectUrl to the app.

  4. The app opens the URL in a Web-View.

  5. The customer performs the payment.

  6. Afterwards, Saferpay will redirect the customer back to one of the corresponding Return URLs (see #11), while also notifying the server.

  7. Saferpay responds with the payment data, which then gets saved on the server.

  8. The server forwards the result and any additional data to the app.

  9. It is also possible to intercept the redirect, so the app may perform a web-to-app switch.

  10. The app displays a success or failure message to the customer, while the server finalizes (Capture etc.) the payment.

The server calls Saferpay, doing either a , or .

The server executes the and forwards the result to the app.

The app confirms the receipt of the result, so the server may finalize and the payment, while the app either displays a success, or a failure message to the customer.

, as the form is hosted on the card holders device and the data is sent to Saferpay.

All 3rd party payment methods are exclusively provided via the , since they mostly require web-based redirects to be processed.

The server calls Saferpay, doing a request.

The server executes the request to gather the payment data.

At this moment, does not support the Web-View integration. Only the Safari browser itself is supported.

also does not support the Web-View integration.

An exception from this process is Bancontact, which offers an .

Transaction Initialize
Alias Insert
Authorization
capture
This is allowed under PCI
Payment Page
Payment Page Initialize
Payment Page Assert
Apple Pay
Google Pay
transaction interface
Secure Alias Store
alt text
alt text
alternative payment process