For any question, we are one click away

Contact us

Apple Pay

Introduction

Before accepting payments via Apple Pay, follow the steps in the sections below. On completing these steps, you can start developing your mobile application (mobile app development documentation is not included in this document, for more information see Apple Pay documentation).

Create Merchant ID

To create your Merchant ID, follow these steps.

  1. In the personal area of the Apple Member Center, go to Certificates, Identifiers & Profiles.
  2. In the Identifiers section select Merchant IDs.
  3. On the resulting page click + (Add) in the right upper corner.
  4. In the Merchant ID Description and Identifier fields enter a description of your Apple merchant identifier and the identifier itself accordingly.
  5. Click Continue.
  6. On the resulting page check the data you entered and click Register.
  7. On the resulting page click Done.

Certificate registration

To receive payments via Apple Pay, you need to have a key pair (private and public key) and the corresponding public key certificate. The required actions in the personal cabinet depend on whether you already have a key pair and the corresponding certificate or not.

Initial conditions Required steps
You do not have a key pair and the public key certificate
  1. Create a key pair
  2. Download CSR from the personal cabinet
  3. Sign the certificate at Apple Pay

After that the following actions will become available.
You have a key pair and your public key certificate is registered at Apple Pay Upload the file containing your key pair
After that the following actions will become available.

Create new certificate

To create a key pair, follow these steps.

  1. Log in to your personal cabinet and click in the left panel (Certificates section).
  2. Select Apple Pay.
  3. Click Create key pair.
    The following form will display.
  4. Fill in the required fields (see the table below).
Setting Description

Encryption algorithm

This radio button allows to select one of the two cryptographic algorithms that will be used for key pair generation.
  • RSA - RSA algorithm.
  • ECC - elliptic curves cryptography .

Country (C)

Enter two-letter code of the country where your organization is located.

Locality Name (L)

Enter the name of the locality where your organization is located.

Organization Name (O)

Enter the name of your organization.

Apple ID

Merchant Apple ID.

State Name (ST)

Enter state name where your organization is located.

Common Name (CN)

Enter the domain name of your site, for example, test.com.

Organization Unit (OU)

Enter the name of your organization unit.

The created key pair will be displayed in the Apple Pay section (see the figure below).

Proceed to CSR download

Upload previously created certificate

To upload an existing key pair, follow these steps.

  1. Log in to your personal cabinet and click in the left panel (Certificates section).
  2. Select Apple Pay.
  3. In the Merchant identification certificates section click Add key.
    The following form will be displayed.
  4. Fill in the following fields.
    • Apple ID - enter your Merchant Apple ID.
    • Password - enter the password for your PKCS12 file.
    • Default domain - enter the domain of your online store.
  5. Drag your key pair file to the designated area on the page.
    It will be displayed below.
  6. Click Create. The uploaded key pair will be displayed in the Merchant identification certificates section.

After uploading your key pair the following actions will become available.

Export CSR

To download CSR, follow these steps.

  1. Log in to your personal cabinet and click in the left panel (Certificates section).
  2. Select the required payment service (Apple Pay, Google Pay, or Samsung Pay).
  3. Click next to your certificate and select Download CSR (see the figure below).

    Save file dialog will display.
  4. Specify the path to which the file will be saved or save it to the default folder.

Also, the following actions are available.

Edit Merchant ID

To edit your Apple Merchant ID, follow these steps.

  1. Log in to your personal cabinet and click in the left panel (Certificates section).
  2. Select Apple Pay.
  3. Click and select Edit. (see the figure below).

    The following form will be displayed.
  4. Edit Apple ID field and click Confirm.

Disable certificate

To disable a certificate (key), follow these steps.

  1. Log in to your personal cabinet and click in the left panel (Certificates section).
  2. Select the required payment service (Apple Pay, Google Pay, or Samsung Pay).
  3. Click next to your certificate and select Disable key (see the figure below).

    The following dialog will display.
  4. Click Confirm.

Whether a disabled certificate is displayed in the personal cabinet depends on Allowed certificates setting that is at the upper left corner of the Certificates section (see the figure below).

Setting Description
Allowed certificates enabled Disabled certificates are not displayed in the Keys list.
Allowed certificates disabled Disabled certificates are displayed in the Keys list. Allowed cell will have False value (see the figure below).

Actions necessary for web integration

For Web integration, follow these steps.

  1. Register and confirm your domain in Apple.
    • If the payment page is located on your side, register your domain.
    • If the payment page is located on the payment gateway side, specify the payment gateway domain.
  2. Create a merchant identification certificate, convert it to a .pem file, and upload it to your server.

This certificate is used to authenticate connections to Apple Pay servers.

Registration of a domain in Apple

To register a certificate in Apple, follow these steps.

  1. Log in to your Apple developer account at https://developer.apple.com.
  2. Follow Apple developer account help instructions to register a domain.

Select the previously created merchant ID when prompted.

Integration scheme

sequenceDiagram participant Payer participant Merchant's resource participant Apple Pay system participant Payment gateway Payer->>Merchant's resource: 1. Selecting to pay with Apple Pay Merchant's resource->>Apple Pay system: 2. Sending payment details Apple Pay system->>Apple Pay system: 3. Creating PKPaymentToken Object with PaymentData Apple Pay system-->>Merchant's resource: 4. Sending payment data Merchant's resource->>Merchant's resource: 5. Extracting PaymentData and encoding the content in Base64 Merchant's resource->>Payment gateway: 6. Request for payment with PaymentData value encoded in Base64 Payment gateway->>Payment gateway: 7. Decryption of the payment data and payment Payment gateway-->>Merchant's resource: 8. Sending a response with the payment result Merchant's resource-->>Payer: 9. Displaying the result
  1. The user in the mobile application selects the payment option using Apple Pay.
  2. The payment data is sent to the Apple Pay system for processing.
  3. To process the payment data an object PKPaymentToken Object, which has paymentData attribute, is created in the Apple Pay system (here and further see Apple Pay documentation).
  4. Apple Pay sends a response to the merchant (mobile application).
  5. The merchant exctracts paymentData attribute out of received PKPaymentToken Object object and encodes its contents in Base64.
  6. The merchant creates a payment request containing paymentDataattribute, which is received from the Apple Pay response and encoded in Base64, and sends it to the payment gateway for processing (see Request for payment via Apple Pay).
  7. The payment system processes the request.
  8. The payment system returns a response with the result.
  9. The mobile application displays the payment result to the user.

Link Description
Apple Pay A section of the apple.com site containing general information on Apple Pay.
Developer Apple Pay A section of the apple.com site dedicated to developers and containing links and reference information concerning Apple Pay.
Apple Pay Sandbox A section of the apple.com site containing information on testing.
Apple Pay Guide A section of the apple.com site containing a programming reference.
Apple Pay Guidelines A section of the App Store reference dedicated to Apple Pay.
Apple Pay API API reference (application programming interface).
PKPaymentToken Object structure Description of the PKPaymentToken Object structure.
Login page The development environment login page.
Getting Started with Apple Pay PDF document containing general information on Apple Pay and reference links.
Apple Pay Marketing Guidelines Description of how to add the Apple Pay button on your website.

Google Pay

Introduction

There are several implementation options for Google Pay™ that support both CRYPTOGRAM_3DS and PAN_ONLY authentication methods.

Payment option Description
From your mobile application Payment is made from your mobile application installed on customer's mobile device. In this scenario the application requests encrypted data from Google Pay. This data must be sent to the payment gateway.
See also redirection to ACS. Please reference to the respective Google Pay documentation:
From a Web payment page on your side Payment is made from a Web page. In this case, the merchant requests the encrypted payment data from Google Pay. Then the merchant must send this data to the payment gateway.
See also redirection to ACS.
From a Web payment page located on the side of the payment gateway Payment is made from a Web page. In this case, the merchant redirects the customer to the payment page on the payment gateway side. In this case, the merchant redirects the customer to the payment page on the payment gateway side, and must meet Google Pay requirements:

Integration schemes

Payment from a mobile app

sequenceDiagram participant Customer participant Application participant Google Pay participant Payment gateway Customer->>Application: 1. Select Google Pay payment. Application->Google Pay: 2. Request masked card data. Google Pay-->>Application: 3. Response to the request. Application-->>Customer: 4. Display of the masked card data. Customer->>Application: 5. Payment confirmation. Application->>Google Pay: 6. Request the encrypted card data. Google Pay->>Google Pay: 7. Data encryption. Google Pay-->>Application: 8. Return the encrypted payment data. Application->>Payment gateway: 9. Google Pay payment request. Payment gateway->>Payment gateway: 10. Decrypt the payment data, and payment. Payment gateway-->>Application: 11. Payment result. Application-->>Customer: 12. Payment result.
  1. A customer selects to pay via Google Pay.
  2. The application requests masked card data from Google Pay.
  3. Google Pay returns masked card data to the application.
  4. The application displays the masked card data to the customer.
  5. The customer confirms payment.
  6. The application requests encrypted card data from Google Pay .
  7. Google Pay encrypts the data using merchant's public key.
  8. Google returns the encrypted payment data to the application.
  9. The application sends a Google Pay payment request to the payment gateway, the request contains the token received from Google Pay.
  10. The payment gateway decrypts the received token and processes the payment.
  11. The payment gateway returns the payment result to the application.
  12. The application displays the payment result to the customer.

Payment page is on the the online store side

sequenceDiagram participant Customer participant Merchant participant Google Pay participant Payment gateway Customer->>Merchant: 1. Select payment via Google Pay. Merchant->>Google Pay: 2. Request for Google Pay payment. Google Pay->>Google Pay: 3. Encrypt payment data. Google Pay-->>Merchant:4 . Return encrypted data. Merchant->>Payment gateway: 5. Google Pay request. Payment gateway->>Payment gateway: 6. Data decryption, and payment. Payment gateway-->>Merchant: 7. Payment result. Merchant-->>Customer: 8. Payment result.
  1. The customer creates an order on the online store Website and chooses to pay via Google Pay.
  2. The online store generates a request for Google Pay.
  3. The Google Pay generates the encrypted payment data.
  4. The online store receives the encrypted payment data.
  5. The online store generates a Google Pay payment request, the request contains the received encrypted payment data.
  6. The payment gateway decrypts the received data and makes the payment.
  7. The payment gateway returns the payment result to the online store.
  8. The payment result is displayed to the customer.

Payment page is on the payment gateway side

sequenceDiagram participant Customer participant Merchant participant Payment gateway participant Google Pay Customer->>Merchant: 1. Order placement. Merchant->>Payment gateway: 2. Order registration. Payment gateway-->>Merchant: 3. Order number and redirection URL. Merchant-->>Customer: 4. Customer redirection. Customer->>Payment gateway: 5. Proceed to the URL received. Payment gateway->>Payment gateway: 6. Display the payment form. Customer->>Payment gateway: 7. Select Google Pay as a payment method. Payment gateway->Google Pay: 8. Data exchange. Payment gateway->>Payment gateway: 9. Make payment. Payment gateway-->>Customer: 10. Redirection to the final page. Customer->>Payment gateway: 11. Open of the final page. Payment gateway-->>Customer: 12. Display payment status to the customer.

If the payment page is located on the Google Pay side, the scheme is the following.

  1. A customer creates an order on the merchant's Website.
  2. The merchant registers the order in the payment gateway.
  3. The payment gateway returns a unique order number and the URL to which the customer must be redirected.
  4. The store system redirects the customer to the URL from step 3.
  5. The customer's browser opens the URL.
  6. The customer receives a payment form.
  7. The customer choose to pay via Google Pay and confirms the choice.
  8. The payment data is exchanged between the payment gateway and Google Pay - the payment gateway receives the payment data.
  9. The payment gateway processes the payment.
  10. The customer is redirected to the final page.
  11. The customer's browser displays the final page.
  12. The payment status is displayed.

Payment via Google Pay using 3DS 2.0

When you use payment via Google Pay with the /google/payment.do or google/paymentDirect.do request, you can use customer authentication with 3DS 2.0. In this case, you must send a payment request to the payment gateway twice for each transaction. Sending the first request initiates the 3DS 2.0 authentication procedure, and sending the second request continues the procedure with the data received from the 3DS server (an additional component that interacts with payment systems and ACS).

If the customer is redirected to the online store's page after authentication, you must complete the payment by sending the finish3dsVer2Payment.do request.

Payment with google/paymentDirect.do using 3DS 2.0

Below is the integration scheme with the google/paymentDirect.do request (token decryption on your side) using 3DS 2.0.

sequenceDiagram autonumber participant Client as Client participant Merchant as Merchant participant Google Pay participant PG as PG participant 3DS server participant ACS Client ->> Merchant: Select Google Pay payment Merchant ->> Google Pay: Request the cards list Google Pay -->> Merchant: List of masked cards Merchant ->> Google Pay: Select a card for payment Google Pay -->> Merchant: Encrypted paymentToken Merchant ->> Merchant: paymentToken decryption Merchant ->> PG: The first google/paymentDirect.do request
(decrypted token in Base64) PG -->> Merchant: Response to the first request Merchant ->> 3DS server: Call a hidden iframe (threeDSMethodURLServer) opt threeDSMethodURL is in response Merchant ->> ACS: Call a hidden iframe (threeDSMethodURL) end Merchant ->> PG: The second google/paymentDirect.do request PG -->> Merchant: Response to the second request opt Redirection to ACS is required Merchant ->> ACS: CReq (Challenge request) ACS -->> Client: HTML form to pass authentication Client ->> ACS: Confirmation of authenticity ACS -->> Client: Authentication result and redirection to the store page Merchant ->> PG: finish3dsVer2Payment.do PG -->> Merchant: Response to the request end Merchant ->> PG: Order status request PG -->> Merchant: Response to the order status request Merchant -->> Client: Displaying the result
  1. A customer selects to pay via Google Pay.
  2. The application requests the list of cards from Google Pay.
  3. Google Pay returns the list of masked cards to the application.
  4. The customer selects a card for payment, the card data is sent to Google Pay.
  5. Google Pay sends encrypted paymentToken to the application.
  6. The merchant decrypts paymentToken.
  7. Order payment - stage 1. The merchant sends decrypted paymentToken to the payment gateway by sending the google/paymentDirect.do request.
  8. The payment gateway checks on the 3DS server whether the customer can authenticate using the 2.0 Protocol and sends the response. The response also returns the following parameters:
    • is3DSVer2 - 3DSv2 authentication capability flag (true/false)
    • threeDSServerTransId - transaction identifier assigned by the 3DS server.
    • threeDSMethodURLServer - address of the 3DS server for collecting browser data.
    • threeDSMethodURL - (optional) address of the ACS server for collecting browser data.
    • threeDSMethodDataPacked - (optional) data for collecting browser data on ACS.
  9. The merchant calls threeDSMethodURLServer in a separate "iframe" with the help of the POST method. This allows the 3DS server to collect data about the customer's browser.
  10. (Optional step) If threeDSMethodURL and threeDSMethodDataPacked parameters were received in the response to the order payment request, the merchant calls threeDSMethodURL in a separate iframe using the POST method. In this method, it's necessary to pass the value, received in the threeDSMethodDataPacked parameter in the response to the order payment request. It is necessary to pass it in a parameter called threeDSMethodData. This allows the ACS to collect data about the customer's browser.
  11. Order payment - stage 2. The merchant resends the google/paymentDirect.do request to complete the order (or make a money transfer). You must pass the threeDSServerTransId parameter - the transaction identifier which was created by the 3DS server and returned at step 8. Additionally, to redirect the customer to the store's page after the order is paid, the redirect link may be passed in the parameter threeDSVer2FinishUrl.
  12. The payment gateway interacts with 3DS server and ACS to find out if the customer needs to authenticate on ACS and sends the response to the payment request. If the customer needs to authenticate on ACS, the response returns acsUrl – the URL for redirecting to ACS and packedCReq – the packed data for challenge request. Else – the successful payment response is received.
  13. If the customer does not need to authenticate on ACS, go to the step 19 of this procedure.

    If the customer needs to authenticate to the ACS, the payment page is redirected to acsUrl with the creq=packedCReq parameter received at step 12.

  14. ACS displays an HTML form for authentication to the customer.

  15. The customer is authenticated.

  16. ACS redirects the customer to the store's page.

  17. To complete a transaction, the merchant sends the finish3dsVer2Payment.do request to the payment gateway passing the threeDSServerTransId parameter - the transaction identifier which was created by the 3DS server and returned at step 8.

  18. The payment gateway sends the merchant a response to the request.

  19. The merchant sends an extended request for the order status getOrderStatusExtended.do to the payment gateway to find out the order status.

  20. The payment gateway sends a response to the request.

  21. The merchant displays the result page to the customer.

Payment with /google/payment.do using 3DS 2.0

Below is the scheme of payment with the /google/payment.do request (token decryption on the Payment Gateway side) using 3DS 2.0.

sequenceDiagram autonumber participant Client participant Merchant participant Google Pay participant PG participant 3DS server participant ACS Client ->> Merchant: Select Google Pay Merchant ->> Google Pay: Request masked card data Google Pay -->> Merchant: Return the masked card data Merchant -->> Client: Display the masked card data Client ->> Merchant: Payment confirmation Merchant ->> Google Pay: Request encrypted card data Google Pay ->> Google Pay: Data encryption Google Pay -->> Merchant: Encrypted data Merchant ->> PG: The first google/payment.do request
(decrypted token in Base64) PG ->> PG: Token decryption PG -->> Merchant: Response to the first request Merchant ->> 3DS server: Call a hidden iframe (threeDSMethodURLServer) opt threeDSMethodURL is in response Merchant ->> ACS: Call a hidden iframe (threeDSMethodURL) end Merchant ->> PG: The second google/payment.do request PG -->> Merchant: Response to the second request opt Redirection to ACS is required Merchant ->> ACS: CReq (Challenge request) ACS -->> Client: HTML form to pass authentication Client ->> ACS: Confirmation of authenticity ACS -->> Client: Authentication result and redirection to the store page Merchant ->> PG: finish3dsVer2Payment.do PG -->> Merchant: Response to the request end Merchant ->> PG: Order status request PG -->> Merchant: Response to the order status request Merchant -->> Client: Displaying the result
  1. A customer chooses to pay via Google Pay.
  2. The application requests Google Pay masked card data.
  3. Google Pay returns the masked card data.
  4. The application displays the masked card data to the customer.
  5. The customer confirms payment.
  6. The application requests Google Pay the encrypted card data.
  7. Google Pay encrypts the data using your public key.
  8. Google Pay returns the encrypted payment data to the application.
  9. Order payment - stage 1. The merchant sends decrypted paymentToken to the payment gateway by sending the /google/payment.do request.
  10. The payment gateway decrypts the received token.
  11. The payment gateway checks on the 3DS server whether the customer can authenticate using the 2.0 Protocol and sends the response. The response also returns the following parameters:
    • is3DSVer2 - 3DSv2 authentication capability flag (true/false)
    • threeDSServerTransId - transaction identifier assigned by the 3DS server.
    • threeDSMethodURLServer - address of the 3DS server for collecting browser data.
    • threeDSMethodURL - (optional) address of the ACS server for collecting browser data.
    • threeDSMethodDataPacked - (optional) data for collecting browser data on ACS.
  12. The merchant calls threeDSMethodURLServer in a separate "iframe" with the help of the POST method. This allows the 3DS server to collect data about the customer's browser.
  13. (Optional step) If threeDSMethodURL and threeDSMethodDataPacked parameters were received in the response to the order payment request, the merchant calls threeDSMethodURL in a separate iframe using the POST method. In this method, it's necessary to pass the value, received in the threeDSMethodDataPacked parameter in the response to the order payment request. It is necessary to pass it in a parameter called threeDSMethodData. This allows the ACS to collect data about the customer's browser.
  14. Order payment - stage 2. The merchant resends the /google/payment.do request to complete the order (or make a money transfer). You must pass the threeDSServerTransId parameter - the transaction identifier which was created by the 3DS server and returned at step 11. Additionally, to redirect the customer to the store's page after the order is paid, the redirect link may be passed in the parameter threeDSVer2FinishUrl.
  15. The payment gateway interacts with 3DS server and ACS to find out if the customer needs to authenticate on ACS and sends the response to the payment request. If the customer needs to authenticate on ACS, the response returns acsUrl – the URL for redirecting to ACS and packedCReq – the packed data for challenge request. Else – the successful payment response is received.
  16. If the customer does not need to authenticate on ACS, go to the step 22 of this procedure.

    If the customer needs to authenticate to the ACS, the payment page is redirected to acsUrl with the creq=packedCReq parameter received at step 15.

  17. ACS displays an HTML form for authentication to the customer.

  18. The customer is authenticated.

  19. ACS redirects the customer to the store's page.

  20. To complete a transaction, the merchant sends the finish3dsVer2Payment.do request to the payment gateway passing the threeDSServerTransId parameter - the transaction identifier which was created by the 3DS server and returned at step 8.

  21. The payment gateway sends the merchant a response to the request.

  22. The merchant sends an extended request for the order status getOrderStatusExtended.do to the payment gateway to find out the order status.

  23. The payment gateway sends a response to the request.

  24. The merchant displays the result page to the customer.

Requirements for the payment page on merchant's side

Payment page on the merchant's side must meet the following requirements.

paymentsClient.isReadyToPay({allowedPaymentMethods: allowedPaymentMethods})
    .then(function(response) {
      if (response.result) {
        // in this case the button should be displayed
        addGooglePayButton();
      }
    })
    .catch(function(err) {
      // show error in developer console for debugging
      console.error(err);
    });

function addGooglePayButton() {
  var button = document.createElement('button');
  button.className = 'google-pay';
  button.appendChild(document.createTextNode('Google Pay'));
  sbutton.addEventListener('click', onGooglePaymentButtonClicked);
  document.getElementById('container').appendChild(button);
}
var paymentsClient =
    new google.payments.api.PaymentsClient({environment: 'TEST'});
function getGooglePaymentDataConfiguration() {
  return {
    merchantId: '00000000000000000000', //constant for the bank's RBE; for the environment: 'TEST' is not indicated
    transactionInfo = {
        totalPriceStatus: 'FINAL',
        totalPrice: '123.45', //amount in major units
        currencyCode: 'EUR' //ISO 4217
    },
    paymentMethodTokenizationParameters: {
        tokenizationType: 'PAYMENT_GATEWAY',
        parameters: {
            gateway: 'some-bank', //constant for the bank's RBE
            gatewayMerchantId: 'exampleGatewayMerchantId' //merchant identifier in the payment gateway
        }
    },
    allowedPaymentMethods: ['CARD', 'TOKENIZED_CARD'],
    cardRequirements: {
        allowedCardNetworks: ['MASTERCARD', 'VISA']
    }
  };
}
var paymentDataRequest = getGooglePaymentDataConfiguration();
paymentsClient.loadPaymentData(paymentDataRequest).then(function(paymentData){
  processPayment(paymentData);
}).catch(function(err){
  // show error in developer console for debugging
  console.error(err);
});

Create key pair

To create a key pair, follow these steps.

  1. Log in to your personal cabinet and click in the left panel (Certificates section).
  2. Select Google Pay.
  3. In the Keys section click Create key pair.
    The following form will be displayed.
  4. Fill in the Google ID field with your Google ID obtained from Google Pay, then click Confirm.
  5. The created key pair will be displayed in the Keys section (see the figure below).

Download public key

To download your public key, follow these steps.

  1. Log in to your personal cabinet and click in the left panel (Certificates section).
  2. Select Google Pay.
  3. Click next to your certificate and select Download key (see the figure below).
  4. In the Save file window select the path to which the file will be saved or save it to your default folder.

Also, the following action are available.

Edit Google ID

To edit your Google ID, follow these steps.

  1. Log in to your personal cabinet and click in the left panel (Certificates section).
  2. Select Google Pay.
  3. Click next to your certificate and select Edit (see the figure below).
    The following form will be displayed.
  4. Edit the Google ID field, then click Confirm.

Disable certificate

To disable a certificate (key), follow these steps.

  1. Log in to your personal cabinet and click in the left panel (Certificates section).
  2. Select the required payment service (Apple Pay, Google Pay, or Samsung Pay).
  3. Click next to your certificate and select Disable key (see the figure below).

    The following dialog will display.
  4. Click Confirm.

Whether a disabled certificate is displayed in the personal cabinet depends on Allowed certificates setting that is at the upper left corner of the Certificates section (see the figure below).

Setting Description
Allowed certificates enabled Disabled certificates are not displayed in the Keys list.
Allowed certificates disabled Disabled certificates are displayed in the Keys list. Allowed cell will have False value (see the figure below).

Samsung Pay

General information

Before accepting payments via Samsung Pay, follow these steps.

  1. Create an account at https://account.samsung.com.
  2. Using the created account, register at https://pay.samsung.com/developers.
  3. At https://pay.samsung.com/developers create Service and select BPC as your Payment Gateway.
  4. Proceed to the actions in the personal cabinet of the payment gateway:

Create key pair

To create a key pair, follow these steps.

  1. Log in to your personal cabinet and click in the left panel (Certificates section).
  2. Select Samsung Pay.
  3. In the Keys section click Create key pair.
    The following form will be displayed.
  4. Fill in the fields (see the table below).
Field Description

Country (C)

Enter two-letter code of the country where your organization is located.

State Name (ST)

Enter state name where your organization is located.

Locality Name (L)

Enter the name of the locality where your organization is located.

Common Name (CN)

Enter the domain name of your site, for example, test.com.

Organization Name (O)

Enter the name of your organization.

Organization Unit (OU)

Enter the name of your organization unit.

The created key pair will be displayed in the Keys section (see the figure below).

Proceed to CSR download.

Export CSR

To download CSR, follow these steps.

  1. Log in to your personal cabinet and click in the left panel (Certificates section).
  2. Select the required payment service (Apple Pay, Google Pay, or Samsung Pay).
  3. Click next to your certificate and select Download CSR (see the figure below).

    Save file dialog will display.
  4. Specify the path to which the file will be saved or save it to the default folder.

Now you can register your certificate by uploading the CSR to Samsung Pay.

Also, you can disable your certificate.

Complete registration

In your profile at https://pay.samsung.com/developers upload the certificate signing request as Merchant CSR (merchant certificate signing request).

Disable certificate

To disable a certificate (key), follow these steps.

  1. Log in to your personal cabinet and click in the left panel (Certificates section).
  2. Select the required payment service (Apple Pay, Google Pay, or Samsung Pay).
  3. Click next to your certificate and select Disable key (see the figure below).

    The following dialog will display.
  4. Click Confirm.

Whether a disabled certificate is displayed in the personal cabinet depends on Allowed certificates setting that is at the upper left corner of the Certificates section (see the figure below).

Setting Description
Allowed certificates enabled Disabled certificates are not displayed in the Keys list.
Allowed certificates disabled Disabled certificates are displayed in the Keys list. Allowed cell will have False value (see the figure below).

Integration schemes

Payment from a mobile application

sequenceDiagram participant Payer participant Mobile application participant Samsung Pay participant Payment gateway Payer->>Mobile application: 1. Select Samsung Pay. Mobile application->>Samsung Pay: 2. Payment request. Samsung Pay->>Samsung Pay: 3. Device check. Samsung Pay-->>Mobile application:4 . Response containing 3ds.data parameter. Mobile application->>Payment gateway: 5. Payment request. paymentToken parameter contains 3ds.data. Payment gateway->>Payment gateway: 6. Data decryption and payment. Payment gateway-->>Mobile application: 7. Payment result. Mobile application-->>Payer: 8. Display the result.
  1. A Customer selects Samsung Pay as a payment method.
  2. The application sends payment details to Samsung.
  3. Samsung checks the application.
  4. Samsung sends a response to the application containing, among other things, the 3ds.data parameter with the encrypted data about the payment.
  5. The merchant sends a payment request to the payment gateway. The contents of 3ds.data received from Samsung is included in the paymentToken parameter.
  6. The payment gateway decrypts the contents of paymentToken and makes the payment.
  7. The payment gateway sends the payment result to the application.
  8. The application displays the result to the customer.

Payment from a Web page on the payment gateway side

sequenceDiagram participant Customer participant Merchant's website participant Payment gateway participant Samsung Pay Customer->>Merchant's website: 1. Order placing. Merchant's website->>Payment gateway: 2. Payment request. Payment gateway-->>Customer: 3. Redirection to the payment gateway page. Customer->>Payment gateway: 4. Payment via Samsung Pay. Payment gateway->Samsung Pay: 5. Data exchange. Payment gateway-->>Customer: 6. Redirection to Samsung Pay page. opt The customer's mobile device is not linked to a Samsung account. Customer->>Samsung Pay: 7. Enter login. end Samsung Pay-->>Customer: 8. Request authentication data. Customer->>Samsung Pay: 9. Authentication. Payment gateway->>Samsung Pay: 10. Exchange payment data. Samsung Pay-->>Customer: 11. Display payment result.
  1. A customer creates an order and starts the payment procedure.
  2. The merchant sends an order registration to the payment gateway:
  3. The merchant sends a payment request to the payment gateway.
  4. The customer selects to pay via Samsung Pay.
  5. The payment gateway communicates with Samsung Pay.
  6. The customer is redirected to the Samsung Pay page.
  7. The customer enters their login.
  8. The application on the customer's mobile device requests authentication data.
  9. The customer is authenticated on their device.
  10. The payment gateway exchanges payment data with Samsung Pay.
  11. The customer is redirected to the payment result page.

Payment from a Web page on the merchant's side

sequenceDiagram participant Customer participant Merchant's Website participant Payment gateway participant Samsung Pay Customer->>Merchant's Website: 1. Place an order. Merchant's Website->>Payment gateway: 2. Order registration. Payment gateway-->>Merchant's Website: 3. Order identifier. Merchant's Website-->>Customer: 4. Redirection to the payment page. Customer->>Merchant's Website: 5. Receive the payment page. Merchant's Website-->>Customer: 6. Payment page. Customer->>Merchant's Website: 7. Request Samsung Pay payment. Merchant's Website->>Payment gateway: 8. Payment via Samsung Pay. Payment gateway->Samsung Pay: 9. Data exchange. Payment gateway-->>Merchant's Website: 10. Response to Samsung Pay payment request. Merchant's Website->>Samsung Pay: 11. Redirect the customer to the Samsung Pay page. alt No link between the device and Samsung ID. Samsung Pay->>Customer: 12. Request Samsung ID. Customer-->>Samsung Pay: 13. Enter Samsung ID. end Samsung Pay-->>Customer: 14. Prompt to check linked devices. Samsung Pay->>Customer: 15. Phone authorization request. Customer-->>Samsung Pay: 16. Authorization confirmation. Payment gateway->>Samsung Pay: 17. Data exchange. Payment gateway-->>Merchant's Website: 18. Payment result. Merchant's Website-->>Customer: 19. Payment result.

Payment from a a payment page on the merchant 's side.

  1. A customer creates an order on the merchant 's Website.
  2. The merchant sends an order registration request to the payment gateway.
  3. The payment gateway registers the order and returns the ID of the created.
  4. The store redirects the customer to the merchat's payment page.
  5. The customer's browser opens the merchant's payment page.
  6. The customer gets the payment form.
  7. The customer chooses to pay via Samsung Pay Web.
  8. The merchant sends a payment request via Samsung Pay to the payment gateway.
  9. The payment gateway communicates with Samsung Pay.
  10. The payment gateway sends a response to the payment request.
  11. The payment form redirects the customer to the Samsung Pay page. For this, the JavaScript scenario that calls the connect function is used. This function must send the data from the response received from the payment request.
  12. A form for entering the ID is displayed to the customer.
  13. The customer enters their ID and confirms the link between their ID and device.
  14. Samsung Pay prompts customer authentication.
  15. Samsung Pay sends a notification to the customer's device, so they can select a payment card and confirm the payment.
  16. The customer confirms the payment.
  17. Samsung Pay communicates with the payment gateway.
  18. The payment gateway sends the payment result to the payment page.
  19. The payment page displays the result to the customer.
Categories:
eCommerce API V1
Categories
Search results