Processing payments via SMS-Tan: This is a mandatory security standard for banks - and their customers. But there is a long way to go before it goes live on websites or in apps. The development of secure payment systems involves numerous tests and the question: How can development teams conduct secure tests without stumbling blocks?
To test online payment transactions, developers:need test SMS. These individual TANs must be entered at the respective bank. But how does the testing team get hold of the TAN? At denkwerk, we developed and built an SMS gateway with two-factor authentication. A test SMS is sent via a Raspberry Pi computer in a Slack channel. This allows everyone involved in WebDev to test the processes for smoothness without any obstacles. To help others, we've posted the instructions to GitHub for rebuilding!
André Laugks, our Technical Director, tells us how it's done:
We wanted to test the payment process of an e-commerce platform we support in production. Now, since January 1, 2021, the introduction of the 3D Secure 2.0 messaging protocol, two-factor authentication (2FA) by a bank is mandatory. For a test, we firstly needed a real credit card, since test credit cards are not supported by the payment gateway. Second, to test a PayPal payment in production, the PayPal account is secured with two-factor authentication (2FA) via SMS-TAN.
Our idea was to test a payment process in an automated way using our own SMS gateway. One scenario was to run a Selenium test where the user journey would be recreated and all form fields of a user would be filled in with data. Through this test, we could run through an order process, where the credit card data entry would be auto-completed. This test process accepts the SMS, extracts the TAN from the SMS, and completes the ordering process.
This sounded easier than it is, because there were dependencies to third parties: Once the payment provider, who provides the credit card form. After entering the form, it forwards the credit card data to the bank, where the TAN has to be entered automatically.
Another obstacle was that in our case, with automated and recurring testing, we would be purchasing a finite product. With low availability, this would no longer be available to 'real' customers and clients, as long as we did not cancel our purchase. Of course, a virtual product could also be made available for testing.
But first things first: Before Covid-19 - and when our entire team was still working onsite in the office, we used a Samsung S5 smartphone.
To this device, the issuing bank sent one SMS TAN at a time. All developers involved and responsible for the payment process were able to conveniently read the TANs from the smartphone and accordingly test the payment process in production.
The Samsung S5 was on power and charging, so reading the SMS TAN was a bit of a hassle. As a result, we installed the app IFTTT on the S5 and redirected the SMS messages to a channel of the communication software Slack, to which the developers had access.
After the outbreak of the pandemic, it helped the team in the home office a lot to receive the SMS messages via the Slack channel - because everyone concerned had access to it.
Then, all of a sudden, no more SMS messages reached us on the Slack channel. Only a restart of the app brought relief: we traced this back to the Android version, for which there were no more updates.
First, we evaluated several SMS gateway providers that offer interesting features, such as something like creating a virtual mobile number for the bank, forwarding to 1-n more smartphones, or providing an API. However, SMS gateway providers are more targeted at businesses that communicate and send information to their customers via SMS.
On the one hand, however, we didn't want to change the mobile number again at the bank, and on the other hand, we weren't convinced by the monthly costs.
We came to the conclusion: let's implement our own SMS gateway! The functionalities we needed were manageable - accept SMS and forward them internally.
We initially sent the SMS to the Slack channel again, but switched to a mini-application using the Symfony and Bootstrap frameworks for this purpose. This application provides a RESTful endpoint (API) that the Raspberry Pi computer uses to route the SMS to the application. Finished was our SMS gateway!
Raspberry Pi 4
Huawei E173 UMTS Stick
simcard
Raspbian GNU/Linux 10 (Buster)
Gammu (v1.40.0) and Gammu-smsd (v1.40.0)
picocom v3.1
modeswitch v2.5.2
Make sure that the Raspberry Pi is updated with a fresh installation of Raspbian OS 10 (Buster) on an SD card.
The complete instructions and configuration are available in the GitHub repository. Alternatively: instructions and configuration in the GitHub repository.