📜 ⬆️ ⬇️

Simple acceptance of bank card payments in Windows Universal Apps

In 2013, PayOnline, with the support of Microsoft, released the PayOnline Payment SDK . This allowed developers of mobile applications under Windows (at that time - under the Windows Store and Windows Phone) to integrate payment acceptance into applications in a matter of minutes. In this post we will briefly talk about the Payment SDK, its transition to Universal Apps, and the support of recurrent (regular) payments in applications that have appeared.




The video from one of Windows Camp, where PayOnline’s team lead showed a bit of “street magic”, helps to understand what the PayOnline Payment SDK is: showed in real-time how the SDK is integrated into the application and conducted a test transaction.
')


Since then, Microsoft has the opportunity to create Universal Apps - applications adapted for use on both smartphones and desktops. As promised by Microsoft's guideline, the transition was easy and quick (we’ll talk about this later).

Also in 2014, our SDK received support for recurring payments (regular payments initiated by the payer and debited from the payer's card without its participation). This type of payment is strongly recommended to use services that operate on the basis of a paid subscription model: the payer will be able to acquire card data once and agree to automatic deductions once, for example, in a quarter.

First things first.

WHY DEVELOP A PAYMENT SDK APP?


PayOnline provides Internet acquiring services for sites and applications that have commercial functionality — that is, legally allowed goods and services that sell money. To integrate payment acceptance into mobile applications, in the early 2010s, a Pay-Mobile payment solution was developed. Since then, we have been constantly engaged in simplifying the connection procedure both from a technical and operational point of view. One of the tasks aimed at simplifying technical integration is the implementation of the Payment SDK for popular mobile platforms.

Like any “adult” payment service provider, PayOnline has its own API. We transfer it to the developers, and from the received “designer” they build on their side that part of the payment service that will be responsible for the interaction of the payer and the acquiring bank.

Internet acquiring is a method of receiving money on the Internet, and, accordingly, fraud protection technologies have been developed taking into account the specifics of the Internet. 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.

How 3D Secure Works
Most often, the 3-D Secure protocol at work looks like this: you make a payment on the website or in a store, enter the card details, then go to the issuing bank page, 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 verifying 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 through another channel (for example, via SMS) the code that 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 make a full-fledged native application and do not want to embed browser support?

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.

And here we come to the most interesting - the description of the SDK, which allows you to quickly and smoothly integrate card payments into applications.

FIELD NOTES: USING PAYMENT SDK


Code example


Consider sample code for a Windows Store application. It is enough to ensure acceptance of payments in the application.

See sample code
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 the Processing object — the receiving object, which 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 object containing the 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 - the 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.

One-click and regular payments


In 2014, support for recurrent payments was added to the SDK (Rebill technology). Rebill technology allows you to organize regular acceptance of payments in your application: automatic cancellation for services, renewal of subscriptions, etc.

The technology can be used in two modes:
  1. The user once agrees to the terms of the automatic debiting of funds (for example: 100 rubles every 3 months), enters the card details and makes the first payment. Further write-offs are made without the participation of the client.
  2. The user enters the data card when you first pay in the application. Further payments are made without entering the card data, but with the participation of the payer. There may be a 3D Secure protocol check or CVV input, depending on the settings.

Interface


 void Rebill(RebillRequest request); 

The following describes what a recurring payment request looks like.
Property
Type of
Description
RebillAnchor
line
Link to the transaction to make a second payment
OrderId
line
Order ID in your system
Amount
decimal
Re-debit amount
Currency
currency
Recurring currency

Universal Apps Support


With the advent of Microsoft's ability to create Universal Apps , applications that work equally on both the Windows 8.1 platform and the Windows Phone 8 platform, we have prepared an updated SDK with Universal Apps support.

You can independently familiarize yourself with the code of the Windows Universal App demo application, which includes the PayOnline Payment SDK .

Transition to Universal Apps technology


Problems with the transition to a new technology did not arise. After we made a new branch of our SDK, it took only three steps:

After downloading the project, the studio offered to add support for Windows 8.1.



Solution Explorer selected Retarget Windows Store projects to Windows 8.1



Then, in the properties of the project, in the Targeting property, we selected support for Windows 8.1 and Windows Phone 8.1



After rebuilding, it was only necessary to eliminate a couple of comments about obsolete methods.

About development plans Payment SDK


Now we are actively engaged in the technology of p2p transfers, which allows owners of applications and sites to earn on payments made between users (transfer of funds from card to card). The technology can be useful for trading floors, bulletin boards, labor exchanges, crowdfunding organizations, micro-credit services, etc.

We plan to integrate the p2p technology into the PayOnline Payment SDK in the first half of 2015, and we will immediately notify the mobile application development community.

Source: https://habr.com/ru/post/248211/


All Articles