Integration

This subsection provides answers to questions about integration process including configuration and testing of various functionalities.

Figure 1. What is PCI DSS for and how do I comply with its requirements?

Payment Card Industry Data Security Standard (PCI DSS) is a standard for the proper protection of payment card data. It is developed by the PCI Security Standards Council (PCI SSC) and sets requirements for all companies involved in processing, storing, or transmitting payment card data. Complying with the PCI DSS requirements is absolutely mandatory: no parties involved in processing card payments are allowed to process such payments otherwise.

To prove the compliance with the PCI DSS requirements and be allowed to process card payments, merchants are required to provide the corresponding documents to payment systems (such as Visa, Mastercard, and Amex) in time, directly or through providers. Depending on a payment system, there can be different requirements to such documents with regards to the data breach incidents and other cases. Therefore, the necessity for a particular merchant to provide certain documents is considered on a case-by-case basis.

In the case of the Visa and Mastercard payment systems, the PCI DSS compliance documents should be provided to Benker. Thus the following documents are required:

  • From all merchants—the ASV scan report.

    The ASV scanning must be performed by the authorised scanning service providers (PCI SSC Approved Scanning Vendor, ASV) quarterly and after every significant change in the network infrastructure.

  • From the merchants processing over 6 million operations annually (Level 1)—the Attestation of Compliance, AOC.
  • From the merchants processing to 6 million operations annually (Levels 2, 3, and 4)—the Self-Assessment Questionnaire, SAQ.

    With questions on completing the questionnaire, contact the Benker key account manager.

After all required documents have been checked, the merchant can start processing card payments—the merchant is informed about this (as well as about the expiration of the documents validity period) by the Benker key account manager.

In the case of other payment systems, the PCI DSS compliance documents usually should be provided directly to these payment systems, however, the merchants can consult with the key account manager about the necessity of providing these documents to Benker.

Figure 2. What are the URLs for sending requests?

Each of the Benker payment platform interfaces uses its own base URL.

This is important to keep in mind, for example, when you use Payment Page and Gate for different actions: you can generate a token via Payment Page and then make a payout with this token via Gate. To request balance information about this payout via Data API, you can use yet another base URL: https://data.benker.io/v1.

Information about the base URLs, request structures, and other features of the interfaces is provided in sections with the descriptions of these interfaces. The URLs for program and customer actions are listed below:

  • https://api.benker.io is for interaction via Gate. For example, the URL for a payment status request is https://api.benker.io/v2/payment/status. For more information about working with the Gate API requests, see Request format.
  • https://paymentpage.benker.io is for interaction via Payment Page. For example, a GET payment request is GET /payment?payment_currency=EUR&project_id=42&payment_amount=1000&... HTTP/1.1 Host: https://paymentpage.benker.io. For more information about working with the Payment Page API requests, see Request format.
  • https://data.benker.io/v1 is for interaction via Data API. For example, the URL for an account balances request is https://data.benker.io/v1/balance/get. For more information about working with the Data API requests, see Using Data API.
  • dashboard.benker.io is for merchant employees to access the Dashboard web interface.
Figure 3. What are the differences between payment and operation?

Payment within the platform is a comprehensive record of one settlement between a merchant and a customer. The payment is considered completed upon settlement between the merchant and the customer as part of the service provided by the merchant (which includes the corresponding payment request initiated by the merchant).

Operation within the platform is a single action with funds performed during a payment. Processing a single payment may require one or more operations. Such a division is helpful in terms of controlling settlements at the level of payments and specific operations.

Each payment in the platform has its identifier (payment_id) that is unique within a project. Such IDs can include numbers, Latin letters, and other characters in the UTF-8 encoding, and their length must not exceed 255 characters—for example, payment-123 or cosmoshop.sale_456. If a request is valid, the payment is registered in the platform and the appropriate operation is initiated for this payment. Each operation gets an identifier (operation_id) that is unique within the platform. These IDs are passed in callbacks, and you can use them in the Dashboard interface.