Tackling Payments in Mobile Apps

Handling payments within an application can be a daunting task. As a developer, you want to handle the user’s payment information securely. There are many options available to handle payments, but when selecting an implementation you need to consider your application’s functionality. For this article, we will be focusing on handling a user’s payment to charge a user for a service outside of the app. 

 

As a user, you don’t want to have to enter your payment info every time you are charged. Yet on the other hand as a developer, you do not want to store a user’s actual card data. So you need a way to store the user’s payment securely without having the user enter their information every time. There are many SDKs out there to help you with this problem. Depending on your tech stack it may direct you towards a certain solution. Going with a third-party solution can also help reduce the PCI (Payment card industry) scope.

Putting It In Action

For our solution, Slora by Globalvia, we needed to store a user’s payment to charge when the user travels through a toll. Bolt-Mobile payment solution was selected to handle payments within the app. This product handles payments client-side(Android and iOS SDKs) as well as server-side (CardPointe Gateway API). On the client-side, this solution handles tokenizing and encrypting the users’ card data.

Bolt provides SDKs for both iOS and Android. For cross-platform technologies, you will need to wrap the SDK in a native module for use in your cross-platform framework (Flutter, React Native, etc.). This will allow you to write native code to access the Bolt SDK to communicate with your cross-platform code.

How It Works

The SDK gives you the ability to tokenize the user’s card data that has been entered into a text field. Specifically, all that is needed for tokenization is the card number and CVV Along with the tokenization, it will give access to the card type as well as the last four digits of the card.

These properties, as well as expiration date, will be sent to your server-side application to authorize the payment. The last four, card type and expiration date are safe to store without tokenizing. Our implementation only needed card type, card number, CVV, and expiration date. In other instances, you may need to collect a name or full address. The CardPointe Gateway API (which we will get into in a moment) allows you to store these other properties at no extra cost. We could access the CardPointe API directly from the client-side application.

The benefit of using the SDK is it provides a text field that allows you to handle interactions with the CardPointe API. The text field is developed in such a way that as a developer you never have access to the raw card number. This gives us the assurance that we can’t send to our backend or accidentally log it out. Another convenience from using the SDK is that the text field handles masking all but the last four digits of the card, so no custom code is needed there. Editing a card can be a bit tricky with this tokenized approach.

The Solution

For our solution, we just do a full replacement of the payment on file. If you wanted to do an update you wouldn’t be able to update the card number or CVV as we aren’t storing those values. As previously mentioned, the server-side will use the CardPointe Gateway API to take the card info, with the tokenized card data, passed from the client-side to authorize the payment.

This authorization is to ensure the bank will allow the transfer of funds from the user to the merchant. Once authorized the CardPointe API can be used to refund or charge the user.  PCI compliance should be on every developer’s mind when adding payments to an application. For our application, we can limit our PCI scope by using the Bolt-Mobile solution. Throughout this process, the user’s plain card number is never passed along or stored. The tokenization allows us to store the card and pass it to the payment gateway without having the card number. With the other data (last four, card type, expiration date) passed to our server-side application, this allows us to store this info and display the cards we have on file to the user.

Handling payments within an app is a very common feature but when selecting a payment solution security should be kept in mind. Check out Slora by Globalvia to see it in action!

Caleb Hatcher

Caleb Hatcher

October 8, 2020

Mobile software engineer with experience in cross-platform solutions such as react-native, flutter, and titanium. Graduated from Randolph Macon in 2016 with a major in Computer Science and a minor in Biology. Started the Shockoe indoor soccer team.

More like this delivered right to you:

Sign up for our Newsletter to get our latest posts plus invitations to our events and access to future whitepapers.

Related Posts

Seeing the Member Experience in a “User-Experience” World

Seeing the Member Experience in a “User-Experience” World

In the world of product development, we are often always saying “user” _______. User-centered design, user analytics, user personas, user journeys, etc, etc.It’s a term that holds importance because it is a genuine focus on the end-user experience.  It’s also often...

7 Tips for Utilizing Amazon Alexa to Engage with Customers

7 Tips for Utilizing Amazon Alexa to Engage with Customers

Amazon first released Alexa virtual assistant and smart speaker Echo in late 2014. An in-home virtual assistant is an impressive tool, but creating a seamless user experience with it can be a challenge. So how do companies overcome this challenge? What engagement can...

Ready to drop us a line?