Acceptance of bank card payments in applications - PayOnline Payment SDK
At the end of the summer, PayOnline and Microsoft announced the release of a new product - the PayOnline Payment SDK, which allows mobile application developers to integrate non-cash payments into Windows Store and Windows Phone applications. On September 12, we spoke at the Windows Camp with the presentation of the Payment SDK, met face-to-face application developers and talked about the most interesting aspects of implementing payment acceptance in applications. Much has been written on the Internet, and, in particular, on Habré ( 1 , 2 ), which is Internet acquiring, so I don’t want to repeat myself, let's get straight to the point.
Like any “adult” IPSP (Internet Payment Service Provider), we have our own API that allows you to conduct payment transactions. We transfer the interface to the developers, and from the received “designer” the application developer on its side builds that part of the payment service that will be responsible for the interaction between the payer and the acquiring bank.
Everything is great and smooth as long as the development concerns web sites. Internet acquiring is a method of receiving money on the Internet, and, accordingly, fraud protection technologies have been developed with this in mind.
')
The simplest form of payment acceptance integration in mobile applications is the built-in browser. You need to embed a browser to display the payment page of the acquiring bank or payment gateway - and the page for entering the verification confirmation code 3-D Secure. But what if you do not want to violate the integrity of the design and interface of the application?
In this case, the API that we wrote above comes to the rescue. But when using the API, a significant amount of work on integrating the application with the payment gateway falls on the shoulders of the application developer, especially with regard to the implementation of the 3-D Secure protocol (see the sidebar).
And here we come to the most interesting - the description of the SDK, which allows you to quickly and smoothly integrate card payments into the application.
Consider sample code for a Windows Store application. This is enough to ensure acceptance of payments.
What's going on here.
To make a payment, you must use a Processing object, a receiving object that must implement the IConfiguration interface.
The implementation is very simple, two fields: your ID and secret key, which is issued when you connect.
The Processing object provides four events:
In the latter case, it is necessary to show the user of the issuing bank page to enter a code or password, and process the response. You can do everything manually, or you can use the NavigateToAcsUrl method, which takes as parameters a user control — a browser (it has its own for each platform) and a PayResponse object.
Finally, to call the Pay method, it needs to pass a PayRequest containing the following fields:
A savvy reader, of course, will notice that in our SDK we operate with card numbers, and ask how is PCI DSS? Yes, indeed, applications in which data of bank cards are entered during payment formally fall under the action of the PCI DSS standard, or rather PCI PA-DSS.
What is PCI DSS, we wrote in detail in his post . PCI PA-DSS is a related PCI DSS security standard for payment applications (Payment Card Industry Payment Application).
As it is easy to understand from the scope of the standard, if bank card data is entered into an application, it falls under the standard scope. And it would seem that owners of applications using both API and SDK should think about obtaining a certificate.
However, it is worth noting that, firstly, there are still no clear requirements for mobile applications (as, for example, for online stores), and secondly, for small businesses, certification is strictly mandatory only formally. For example, all online stores that provide customers with the opportunity to pay for an order with a credit card must have a PCI DSS Level 4 certificate, even if the payment itself is made on the secure payment page of the service provider. However, it is clear to everyone that no one will oblige the online store with a card turnover of 20,000 rubles per month to undergo annual certification - and the same situation is observed with PA-DSS certification for mobile applications.
The requirements of the standard apply to applications in which data of bank cards are entered. If the application does not enter billing data, but a certain identifier, the application stops processing card data and there is no need for certification.
In early 2013, we launched the payID project, which allows you to accept payments without entering payment information. The owner of a bank card creates an account in payID, binds to it a bank card and when making payments on sites accepting payments through PayOnline, it does not enter the full card data, but its payID and CVC \ CVV code. This allows you to remove the responsibility for processing bank card data from an online store or application, and the payer to ensure 100% security of your card data and, accordingly, money in the account.
If you integrate payID payments into an application, you can accept payments on cards without embedded payment forms, passing PA-DSS certification, fear and reproach.
As we wrote above, we launched the Windows SDK at the end of this summer, the product is still fresh and is under active development. In general, the sphere of receiving payments by cards in mobile applications is very young in itself. Up to the point that security standards are still being formed in it, it is not controlled as strictly as standard e-commerce.
But the dynamics of the growing popularity of the mobile Internet in Russia, the general transition from phones to smartphones, the growing number of Russian-language applications - all this speaks about the prospects of working in the mobile e-commerce segment, its potential and monetization possibilities.
Now we are thinking about how to safely turn the card holder into the owner of the identifier, if he is already in your application.
There are a lot of topics to think about, no less work - we will be grateful to our customers for constructive criticism, interesting ideas and development proposals for the PayOnline Payment SDK.
You can download from nuget: https://www.nuget.org/packages/PayOnline_PaymentSDK/
Like any “adult” IPSP (Internet Payment Service Provider), we have our own API that allows you to conduct payment transactions. We transfer the interface to the developers, and from the received “designer” the application developer on its side builds that part of the payment service that will be responsible for the interaction between the payer and the acquiring bank.
Everything is great and smooth as long as the development concerns web sites. Internet acquiring is a method of receiving money on the Internet, and, accordingly, fraud protection technologies have been developed with this in mind.
')
One of the methods of protection is the 3-D Secure protocol proposed by the global VISA payment system and adopted as a standard by other payment systems.
Practically everyone who makes purchases on the Internet knows what 3-D Secure is (now in Russia there is a very small proportion of banks issuing cards that do not support this protocol, and their number decreases due to the requirements of the same IPS).
Most often, the 3-D Secure protocol at work looks like this: you make a payment on the website of an online store, enter the card details, then go to the page of the issuing bank, where you enter the code received in the SMS. After that, your payment is successfully completed.
The name 3-D comes from 3-Domain (three domains), as organizations in three domains participate in the verification of payment under this protocol: issuer domain (payer and issuing bank), acquirer domain (payment processing bank, and online store) ) and domain interaction (MPS). This is a simplified scheme for checking payment under the 3-D Secure protocol:
The payer enters these cards in the online store, they reach the acquiring bank (1), go to the IPU (2), from where they are sent to the issuing bank (3). You can find out which bank has issued the card by the first six digits of the card number. The issuing bank informs that the card is subscribed to 3-D Secure, forms a unique code, as well as a link to the code entry page (4). The link is returned to the MSP or IPSP (5), which redirect the cardholder’s browser to this page (6.7). At this moment, the issuer sends the cardholder on another channel (for example, via SMS) a temporary pin code, which he enters on the page. If the code is entered correctly, the issuing bank informs about the successful completion of the check (8), and the funds are debited from the payer's card (9, 10).
Most often, the 3-D Secure protocol at work looks like this: you make a payment on the website of an online store, enter the card details, then go to the page of the issuing bank, where you enter the code received in the SMS. After that, your payment is successfully completed.
The name 3-D comes from 3-Domain (three domains), as organizations in three domains participate in the verification of payment under this protocol: issuer domain (payer and issuing bank), acquirer domain (payment processing bank, and online store) ) and domain interaction (MPS). This is a simplified scheme for checking payment under the 3-D Secure protocol:
The payer enters these cards in the online store, they reach the acquiring bank (1), go to the IPU (2), from where they are sent to the issuing bank (3). You can find out which bank has issued the card by the first six digits of the card number. The issuing bank informs that the card is subscribed to 3-D Secure, forms a unique code, as well as a link to the code entry page (4). The link is returned to the MSP or IPSP (5), which redirect the cardholder’s browser to this page (6.7). At this moment, the issuer sends the cardholder on another channel (for example, via SMS) a temporary pin code, which he enters on the page. If the code is entered correctly, the issuing bank informs about the successful completion of the check (8), and the funds are debited from the payer's card (9, 10).
The simplest form of payment acceptance integration in mobile applications is the built-in browser. You need to embed a browser to display the payment page of the acquiring bank or payment gateway - and the page for entering the verification confirmation code 3-D Secure. But what if you do not want to violate the integrity of the design and interface of the application?
In this case, the API that we wrote above comes to the rescue. But when using the API, a significant amount of work on integrating the application with the payment gateway falls on the shoulders of the application developer, especially with regard to the implementation of the 3-D Secure protocol (see the sidebar).
And here we come to the most interesting - the description of the SDK, which allows you to quickly and smoothly integrate card payments into the application.
Code example
Consider sample code for a Windows Store application. This is enough to ensure acceptance of payments.
private void Pay() { var conf = new Configuration { MerchantId = 1, Key = "PrivateKey", }; var request = new PayRequest { Amount = 30m, Currency = Currency.Rub, OrderId = "335636462808", CardExpMonth = 1, CardExpYear = 2018, CardCvv = 100, CardHolderName = "CARD HOLDER", CardNumber = "4111111111111111", Email = "cardholder@example.com", }; var po = new Processing(conf); po.ThreeDs += po_ThreeDs; po.Success += po_Success; po.Decline += po_Decline; po.Error += po_Error; po.Pay(request); } void po_Error(object sender, Exceptions.PaymentSDKException e) { } void po_Decline(object sender, PayResponse e) { } void po_Success(object sender, PayResponse e) { } void po_ThreeDs(object sender, PayResponse e) { ((Processing)sender).NavigateToAcsUrl(Browser, e); } class Configuration : IConfiguration { public int MerchantId { get; set; } public string Key { get; set; } } What's going on here.
To make a payment, you must use a Processing object, a receiving object that must implement the IConfiguration interface.
The implementation is very simple, two fields: your ID and secret key, which is issued when you connect.
class Configuration : IConfiguration { public int MerchantId { get; set; } public string Key { get; set; } } The Processing object provides four events:
- Success - occurs in case of successful payment.
- Decline - occurs in case of failure to conduct.
- Error - if at the time of the payment any errors occurred, for example, the network is unavailable.
- ThreeDs - you need to undergo additional testing on 3-D Secure.
In the latter case, it is necessary to show the user of the issuing bank page to enter a code or password, and process the response. You can do everything manually, or you can use the NavigateToAcsUrl method, which takes as parameters a user control — a browser (it has its own for each platform) and a PayResponse object.
Finally, to call the Pay method, it needs to pass a PayRequest containing the following fields:
- Amount - amount of payment.
- Currency - currency (supported rubles, US dollars and euros).
- OrderId - ID of the order that you generate in your system.
- CardExpMonth - month of expiration of the card.
- CardExpYear - year of expiry of the card.
- CardCvv - CVC2 / CVV2.
- CardHolderName is the name of the cardholder.
- CardNumber - card number.
- Email - the payer's e-mail.
About PCI PA-DSS
A savvy reader, of course, will notice that in our SDK we operate with card numbers, and ask how is PCI DSS? Yes, indeed, applications in which data of bank cards are entered during payment formally fall under the action of the PCI DSS standard, or rather PCI PA-DSS.
What is PCI DSS, we wrote in detail in his post . PCI PA-DSS is a related PCI DSS security standard for payment applications (Payment Card Industry Payment Application).
- Use: An application that stores, processes, or transfers cardholder data.
- Applicability criteria: storage, processing or transfer of at least one card number (PAN).
- Compliance criterion: 100% of requirements fulfilled.
- Confirmation method: application security audit by an audit organization.
- Confirmation frequency: annually.
As it is easy to understand from the scope of the standard, if bank card data is entered into an application, it falls under the standard scope. And it would seem that owners of applications using both API and SDK should think about obtaining a certificate.
However, it is worth noting that, firstly, there are still no clear requirements for mobile applications (as, for example, for online stores), and secondly, for small businesses, certification is strictly mandatory only formally. For example, all online stores that provide customers with the opportunity to pay for an order with a credit card must have a PCI DSS Level 4 certificate, even if the payment itself is made on the secure payment page of the service provider. However, it is clear to everyone that no one will oblige the online store with a card turnover of 20,000 rubles per month to undergo annual certification - and the same situation is observed with PA-DSS certification for mobile applications.
About the possibility of replacing billing information on the payID payID
The requirements of the standard apply to applications in which data of bank cards are entered. If the application does not enter billing data, but a certain identifier, the application stops processing card data and there is no need for certification.
In early 2013, we launched the payID project, which allows you to accept payments without entering payment information. The owner of a bank card creates an account in payID, binds to it a bank card and when making payments on sites accepting payments through PayOnline, it does not enter the full card data, but its payID and CVC \ CVV code. This allows you to remove the responsibility for processing bank card data from an online store or application, and the payer to ensure 100% security of your card data and, accordingly, money in the account.
If you integrate payID payments into an application, you can accept payments on cards without embedded payment forms, passing PA-DSS certification, fear and reproach.
Pro Future Payment SDK
As we wrote above, we launched the Windows SDK at the end of this summer, the product is still fresh and is under active development. In general, the sphere of receiving payments by cards in mobile applications is very young in itself. Up to the point that security standards are still being formed in it, it is not controlled as strictly as standard e-commerce.
But the dynamics of the growing popularity of the mobile Internet in Russia, the general transition from phones to smartphones, the growing number of Russian-language applications - all this speaks about the prospects of working in the mobile e-commerce segment, its potential and monetization possibilities.
Therefore, we will continue to develop the Payment SDK, and plan to move in several directions:
- Empowering developers: a list of platforms (Android, iOS) and a list of supported programming languages ​​- everything is clear and without comments.
- Translation from card to card: we have an implemented service of transfer from card to card, we already wrote about it on Habré. We are thinking about the implementation of the possibility of integrating this service into applications using the Donation scheme. The owner of the application will be able to avoid the need to register IP, create a business card site and enter into an agreement with the payment gateway. He will only need a bank card to receive transfers.
- Convenient acceptance of payments via payID in applications: why using payID is convenient and advantageous from part of the post “About PCI PA-DSS”. This allows you to avoid certification costs, disclaim responsibility for the card data and attract new customers.
Now we are thinking about how to safely turn the card holder into the owner of the identifier, if he is already in your application.
There are a lot of topics to think about, no less work - we will be grateful to our customers for constructive criticism, interesting ideas and development proposals for the PayOnline Payment SDK.
You can download from nuget: https://www.nuget.org/packages/PayOnline_PaymentSDK/
Source: https://habr.com/ru/post/195854/
All Articles