
Easy credit card payments in Windows Universal Apps
- Tutorial
In 2013, PayOnline, with support from Microsoft, released the PayOnline Payment SDK . This allowed developers of mobile applications for Windows (at that time - for 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 appeared support for recurring (regular) payments in applications.

A video from one of the Windows Camp, in which the team leader PayOnline showed a bit of “street magic”, will help you figure out what the Payment SDK PayOnline is: it 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 that are adapted for use on both a smartphone and a desktop computer. As promised by Microsoft’s guidelines, the transition turned out to be simple and quick (more on this later).
Also in 2014, our SDK added support for recurring payments (regular payments initiated by the payer and debited from the payer's card without his participation). This type of payment is strongly recommended to be used by services operating on the basis of a paid subscription model: the payer will be able to enter the card data once and agree to automatic debiting once, for example, in a quarter.
First things first.
PayOnline provides Internet acquiring services for sites and applications that have commercial functionality - that is, selling legally permitted goods and services for money. To integrate payment acceptance into mobile applications, the Pay-Mobile payment solution was developed in the early 2010s. Since then, we are constantly working to simplify the connection procedure from both a technical and an 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 pass it on to the developers, and from the received “constructor” they on their side build that part of the payment service that will be responsible for the interaction of the payer and the acquiring bank.
Internet acquiring is the reception of money on the Internet, and, accordingly, anti-fraud protection technologies are developed taking into account Internet specifics. One of the methods of protection is the 3-D Secure protocol, proposed by the VISA world payment system and adopted by the standard by other payment systems.
The simplest form of payment acceptance integration in mobile applications is the built-in browser. You need to build in a browser to display the payment page of the acquiring bank or payment gateway - and a page for entering the 3-D Secure verification confirmation code. 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 about above comes to the rescue. But when using the API, a considerable amount of work is put on the shoulders of the application developer to integrate the application with the payment gateway, especially when it comes to implementing the 3-D Secure protocol.
And here we come to the most interesting - the description of the SDK, which allows you to quickly and painlessly integrate card payments into applications.
Consider the sample code for the Windows Store application. It is enough to ensure acceptance of payments in the application.
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 the secret key that is issued upon connection.
The Processing object provides four events:
In the latter case, it is necessary to show the user the page of the issuing bank to enter the code or password, and process the response. You can do everything manually, or you can use the NavigateToAcsUrl method, which takes as a parameter 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:
In 2014, support for recurrent payments (Rebill technology) was added to the SDK. Rebill technology allows you to organize regular payment acceptance in your application: automatic charge-off for services, renewal of subscription, etc.
The technology can be used in two modes:
The following describes what a recurring payment request looks like.
With the advent of Microsoft's ability to create Universal Apps , applications that work equally on both Windows 8.1 and Windows Phone 8, we have prepared an updated SDK with support for Universal Apps.
You can independently familiarize yourself with the code of the Windows Universal App demo application, including the PayOnline Payment SDK .
There were no problems with the transition to a new technology. After we made a new branch of our SDK, it took only three steps:



After the rebuild, it was only necessary to eliminate a couple of comments about obsolete methods.
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 (transfers of funds from card to card). The technology can be useful for trading floors, message boards, labor exchanges, crowdfunding organizations, micro-credit services, etc.
We plan to integrate p2p technology into the PayOnline Payment SDK in the first half of 2015, as we will immediately notify the community of mobile application developers.

A video from one of the Windows Camp, in which the team leader PayOnline showed a bit of “street magic”, will help you figure out what the Payment SDK PayOnline is: it 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 that are adapted for use on both a smartphone and a desktop computer. As promised by Microsoft’s guidelines, the transition turned out to be simple and quick (more on this later).
Also in 2014, our SDK added support for recurring payments (regular payments initiated by the payer and debited from the payer's card without his participation). This type of payment is strongly recommended to be used by services operating on the basis of a paid subscription model: the payer will be able to enter the card data once and agree to automatic debiting once, for example, in a quarter.
First things first.
WHY FOR THE PAYMENT SDK DEVELOPER DEVELOPER?
PayOnline provides Internet acquiring services for sites and applications that have commercial functionality - that is, selling legally permitted goods and services for money. To integrate payment acceptance into mobile applications, the Pay-Mobile payment solution was developed in the early 2010s. Since then, we are constantly working to simplify the connection procedure from both a technical and an 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 pass it on to the developers, and from the received “constructor” they on their side build that part of the payment service that will be responsible for the interaction of the payer and the acquiring bank.
Internet acquiring is the reception of money on the Internet, and, accordingly, anti-fraud protection technologies are developed taking into account Internet specifics. One of the methods of protection is the 3-D Secure protocol, proposed by the VISA world payment system and adopted by the standard by other payment systems.
How 3D Secure works
Most often, the 3-D Secure protocol in work looks like this: you make a payment on the website or in the store, enter the card details, then go to the page of the issuing bank, where you enter the code received in SMS. After that, your payment is completed successfully.
The name 3-D comes from 3-Domain (three domains), since organizations on three domains participate in the payment verification under this protocol: the issuer’s domain (payer and issuing bank), the acquirer’s domain (payment processing bank, and online store) ) and the interaction domain (MPS). This is how a simplified payment verification scheme using the 3-D Secure protocol looks like:

The payer enters the card data in the online store, they reach the acquiring bank (1), are sent to the MPS (2), from where they are sent to the issuing bank (3). You can find out which bank issued the card by the first six digits of the card number. The issuing bank reports that the card is subscribed to 3-D Secure, generates a unique code, as well as a link to the code entry page (4). The link is returned to the TSP or IPSP (5), which redirect the card holder to this page in the browser (6,7). At this point, the issuer sends the cardholder via another channel (for example, via SMS) the code that he enters on the page. If the code is entered correctly, the issuing bank reports on the successful completion of the check (8), and the funds are debited from the payer's card (9, 10).
The name 3-D comes from 3-Domain (three domains), since organizations on three domains participate in the payment verification under this protocol: the issuer’s domain (payer and issuing bank), the acquirer’s domain (payment processing bank, and online store) ) and the interaction domain (MPS). This is how a simplified payment verification scheme using the 3-D Secure protocol looks like:

The payer enters the card data in the online store, they reach the acquiring bank (1), are sent to the MPS (2), from where they are sent to the issuing bank (3). You can find out which bank issued the card by the first six digits of the card number. The issuing bank reports that the card is subscribed to 3-D Secure, generates a unique code, as well as a link to the code entry page (4). The link is returned to the TSP or IPSP (5), which redirect the card holder to this page in the browser (6,7). At this point, the issuer sends the cardholder via another channel (for example, via SMS) the code that he enters on the page. If the code is entered correctly, the issuing bank reports on 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 build in a browser to display the payment page of the acquiring bank or payment gateway - and a page for entering the 3-D Secure verification confirmation code. 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 about above comes to the rescue. But when using the API, a considerable amount of work is put on the shoulders of the application developer to integrate the application with the payment gateway, especially when it comes to implementing the 3-D Secure protocol.
And here we come to the most interesting - the description of the SDK, which allows you to quickly and painlessly integrate card payments into applications.
FIELD NOTES: USING THE PAYMENT SDK
Code example
Consider the sample code for the 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 the secret key that is issued upon connection.
class Configuration : IConfiguration
{
public int MerchantId { get; set; }
public string Key { get; set; }
}
The Processing object provides four events:
- Success - arises in case of successful payment.
- Decline - arises in case of refusal to conduct.
- Error - if any errors occurred at the time of payment, for example, the network is unavailable.
- ThreeDs - An additional 3-D Secure check is required.
In the latter case, it is necessary to show the user the page of the issuing bank to enter the code or password, and process the response. You can do everything manually, or you can use the NavigateToAcsUrl method, which takes as a parameter 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 - payment amount.
- Currency - currency (rubles, US dollars and euros are supported).
- OrderId - ID of the order that you generate in your system.
- CardExpMonth - card expiration month.
- CardExpYear - card expiration year.
- CardCvv - CVC2 / CVV2.
- CardHolderName is the name of the card holder.
- CardNumber - card number.
- Email - payer's e-mail.
Regular payments and one-click payments
In 2014, support for recurrent payments (Rebill technology) was added to the SDK. Rebill technology allows you to organize regular payment acceptance in your application: automatic charge-off for services, renewal of subscription, etc.
The technology can be used in two modes:
- The user once agrees to the conditions of automatic charge-off (for example: 100 rubles every 3 months), enters the card data and makes the first payment. Further charges are made without the participation of the client.
- The user enters the card data at the first payment in the application. Further payments are made without entering card data, but with the participation of the payer. 3D Secure verification may occur or CVV input will depend on the settings.
Interface
void Rebill(RebillRequest request);
The following describes what a recurring payment request looks like.
Property | A type | Description |
---|---|---|
Rebillanchor | line | Transaction reference for re-payment |
OrderId | line | Order ID in your system |
Amount | decimal | Re-charge amount |
Currency | currency | Re-charge currency |
Universal Apps Support
With the advent of Microsoft's ability to create Universal Apps , applications that work equally on both Windows 8.1 and Windows Phone 8, we have prepared an updated SDK with support for Universal Apps.
You can independently familiarize yourself with the code of the Windows Universal App demo application, including the PayOnline Payment SDK .
Switching to Universal Apps Technology
There were no problems with the transition to a new technology. After we made a new branch of our SDK, it took only three steps:
After downloading the project, the studio proposed adding support for Windows 8.1

Solution Explorer selects Retarget Windows Store projects to Windows 8.1

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

After the rebuild, it was only necessary to eliminate a couple of comments about obsolete methods.
About Payment SDK Development Plans
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 (transfers of funds from card to card). The technology can be useful for trading floors, message boards, labor exchanges, crowdfunding organizations, micro-credit services, etc.
We plan to integrate p2p technology into the PayOnline Payment SDK in the first half of 2015, as we will immediately notify the community of mobile application developers.