Android Mobile Application Overview

The mobile application is a key component of Pace Software's payment solutions. The mobile application helps merchants process payments on-the-go using their Android smartphone. The application has a user-friendly interface, and it communicates with the back-end APIs to process payments in real-time.

The following detail some of the features and functions of the mobile application.

Payment processing: The mobile application allows merchants to process payments in real-time, it supports multiple payment types including credit and debit card payments. The application is PCI-compliant and uses the latest security protocols to ensure the security of sensitive customer information.

User Profile The mobile application allows merchants to manage their user profile, they can view and update their contact information, such as email and phone number, and also their company information.

Transaction history: The mobile application allows merchants to view their transaction history, they can view transaction details and also download reports of their transactions.

Application Security: The mobile application uses various security measures to ensure the security of sensitive customer information. The application is PCI-compliant, and it uses the latest security protocols, such as encryption and tokenization, to protect sensitive customer information.

Mobile App Technical Details

The mobile application is built using Kotlin programming language and uses a reactive user interface to provide a smooth and responsive experience for users. The application is built using Amadis kernel, which is a certified, EMV L2 kernel. The application also uses the zKeyBox solution from Zimperium, which is a whitebox cryptographic system that protects keys and secrets within the mobile application.

Agnos EMV L2 Framework

The Agnos EMV L2 Framework is a comprehensive, certified, EMV L2 framework. The kernel provides a secure and reliable environment for processing payments within the mobile application.

Agnos EMV L2 Framework Technical Specification:

Environments: Card Present (Attended, Unattended, Kiosk, MPOS) Card Absent (MO/TO, E-commerce)

Terminal Types: • Classic POS, mPOS, SpoC, CPoC • Classic POS Terminal • Mobile POS Terminal • Contactless CPOC (COTS)

Payment Services: Payment, Refund, Cancellation, Pre-authorization, Cashback, Cash

Technologies: Chip & PIN Contact, NFC Contactless and Magnetic Stripe

KML Library: The KML library is a part of the Agnos EMV Level 2 Framework. The KML library is used to handle the payment process in the mobile application, providing functions for initializing the library, exporting sensitive card data in an encrypted format, and cleaning up resources when the app is closed.

The library consists of three main functions:

The KML2Create() function is called whenever an Agnos class is instantiated by the application, most likely only once at application startup. This function is meant to provide the KML2 context with any elements it may need, however, it can also be used to initialize any other necessary elements in the library.The KML2ExportCardData() function is called once per transaction and is used to retrieve sensitive card data in an encrypted format, which is then passed on to the host or server and inserted into the acquirer message (after decryption). The format of the encryption is determined by the developer implementing the library.The KML2Terminate() function is called when the app is closing and is used to clean up any leftovers and release any resources that were allocated during the usage of the library.

White Box Cryptography: The mobile application uses a whitebox cryptographic system. It leverages white-box cryptography to protect keys and secrets within the mobile application. The solution supports all standard and custom algorithms and works on all platforms and devices. The solution also provides key protection when stored, in transit, and in use, and it keeps keys safe at all times, even on compromised, jailbroken, or rooted devices.

UI: The mobile application uses a reactive user interface, which provides a smooth and responsive experience for users. This means that the application can respond to user interactions in real-time, and it can handle multiple user interactions simultaneously. This approach provides a more engaging and responsive experience for users.

Mobile App Programming Language: The main programming language used for the development of the mobile application is Kotlin. Kotlin is a modern, expressive, and statically-typed programming language that is fully compatible with Java. It provides a safe and efficient way to build mobile applications and it has a modern and expressive syntax that makes it easy to write and maintain code.

Frameworks: The Agnos framework is used for the payment processing functionality of the application. It is a comprehensive, certified, EMV L2 framework that conforms to EMV books II/III, A/B and C-x. The framework provides a secure and reliable environment for processing payments within the mobile application.

Libraries: The mobile application uses several libraries such as XXX for networking, XXX for image loading, and XXX for JSON parsing. These libraries provide a set of pre-built functionality that can be easily integrated into the application, they help reduce development time and improve performance.

Security Libraries: The mobile application uses the zKeyBox solution from Zimperium, which is a whitebox cryptographic system. It leverages white-box cryptography to protect keys and secrets within the mobile application.

Reactive UI: The mobile application uses a reactive user interface, which provides a smooth and responsive experience for users. This means that the application can respond to user interactions in real-time, and it can handle multiple user interactions simultaneously. This approach provides a more engaging and responsive experience for users.

Mobile App Security Measures

This section provides an overview of the various security measures that have been implemented in the mobile application to protect sensitive user data and ensure compliance with industry standards. This section includes sub-sections such as Encryption, which details the methods used to secure data in transit and at rest, and Storage of Sensitive Data, which explains how sensitive user information is stored and protected within the application.

ZShield by Zimperium: ZShield is a mobile application security solution that helps secure the distribution of applications. It provides runtime protection for mobile applications against various types of attacks, such as device compromise, network attacks, and code injection. By integrating ZShield into the mobile application, organizations can ensure that the application is protected against known and unknown vulnerabilities and malicious attacks. Additionally, ZShield provides the ability to detect and prevent security threats in real-time, and the solution is designed to work seamlessly with existing security and IT infrastructures. This allows organizations to easily secure their mobile applications and ensure the secure distribution of their applications to users.

Encryption on the Mobile App: Encryption is a key aspect of data security and it is used to protect sensitive user information from unauthorized access. The mobile application implements encryption at multiple levels to ensure that data is secure both in transit and at rest.

Hosted Exclusively on Google App Store: Hosting a mobile application exclusively on the Google Play Store ensures secure distribution of the application because it is a trusted platform that has strict security protocols in place. Applications submitted to the Google Play Store go through a rigorous review process to ensure they are safe and comply with the platform's policies. The Google Play Store also provides automatic updates to the applications, ensuring that vulnerabilities are quickly patched. Additionally, the store provides security features such as app encryption and privacy protection.

Data in Transit: All data transmitted between the mobile application and the backend servers is encrypted using Transport Layer Security (TLS) protocol. This protocol provides secure communication channels by encrypting data using a combination of symmetric and asymmetric encryption methods. The mobile application also uses certificate pinning to ensure that the certificate presented by the backend servers is valid and belongs to the intended server.

Data at Rest: All sensitive user information stored on the device is encrypted using the Advanced Encryption Standard (AES) algorithm with a 256-bit key. This algorithm is a widely accepted standard for data encryption and it provides a high level of security. The encryption key is securely stored on the device.

Encryption Key Management: The mobile application uses the zKeyBox solution from Zimperium for key management. zKeyBox is a whitebox cryptographic system that leverages white-box cryptography to protect keys and secrets within the mobile application. zKeyBox supports all standard and custom algorithms and it is agnostic security works on all platforms and devices. The solution also provides key protection when stored, in transit, and in use, and it keeps keys safe at all times, even on compromised, jailbroken, or rooted devices.

Storage of Sensitive Data: Sensitive user data such as personal identification numbers (PINs), credit card numbers, and other financial information is never stored on the device in clear text. Instead, this information is encrypted and securely stored on the device using the Keystore on Android. The encryption key is also stored on the device using Zimperium zKeyBox whitebox cryptography.

Encryption of Stored Data: The mobile application uses the Advanced Encryption Standard (AES) algorithm with a 256-bit key to encrypt sensitive user data. This algorithm is a widely accepted standard for data encryption and it provides a high level of security.

Data Retention: The mobile application only retains the minimal amount of user data necessary to provide the service. This data is deleted or anonymized when the user requests it or when it is no longer needed for the provision of the service.

Access Control: The mobile application employs strict access controls to ensure that only authorized personnel have access to sensitive user data. Access controls include role-based access control, multi-factor authentication, and logging of all access attempts.

Steps to Prevent Bypass of Google Play Store for Application Download

Pace Software takes active steps to prevent the hosting of the mobile application on unauthorized sites and take steps to prevent an application from running if it's been downloaded from an unauthorized site.

Side-loading

Side-loading refers to the process of installing an application outside of the official app store. This can be done by downloading the APK file from a third-party source and installing it manually. Pace Software's steps to prevent side-loading include:

Digital signature verification: The mobile app is distributed exclusively on the Google Play Store. The signature is verified on the device before installation to confirm the authenticity of the application.
Application wrapping: This process provides a layer of security to protect against side-loading, as well as tampering and reverse engineering of the application. The Pace Software Mobile Application uses ZShield by Zimperium for application wrapping.
Security policies: Official Pace Software policy restricts the installation of applications from sources other than official app stores.

Jail-breaking (or Rooting)

Jail-breaking or rooting refers to the process of unlocking the full potential of a device by removing the limitations imposed by the manufacturer or operating system. This can allow for the installation of apps from unofficial sources, but can also leave the device vulnerable to security risks. Pace Software's steps to prevent rooted phones from using the mobile application include:

Certificate Pinning: The mobile application verifies the SSL certificate used to secure communication between the app and the server. If the certificate doesn't match what's expected, the app can exit immediately.
Detecting Root: The mobile app can check if the device is rooted by checking for the presence of a specific system file or checking the output of a specific command. If the device is found to be rooted, the app refuses to run.
Tamper Detection: The application uses techniques like code obfuscation, anti-tampering, and code signing to detect if the app's code has been modified. If tampering is detected, the app refuses to run.

Enterprise Deployment

Enterprise deployment refers to the distribution of apps within an organization without going through the official app store. Pace Software's steps to prevent enterprise deployment of the app include:

Code signing: The Pace Software mobile app has a digital signature used to verify its authenticity and prevent modification.
App Store Validation: The Google Play Store validates the authenticity of the application by checking the certificate. The mobile app is configured to only work if it's installed from the Google Play Store.

APK Mirror Sites

APK mirror sites are websites that host APK files for various apps, allowing users to download and install the app outside of the official app store. Pace Software's steps to prevent app hosting on unauthorized sites include:

Code Obfuscation: Obfuscating the code of the mobile application makes it harder for attackers to reverse-engineer the code and upload it to mirror sites.
Signature Verification: Signature verification within the application confirms that the code has not been tampered with and is being run from the source.
Encrypting Sensitive Data: Encrypting sensitive data within the application makes it less valuable for attackers to distribute it on APK mirror sites.
Using App Store Optimization (ASO) Techniques: By optimizing the application listing on the Google Play Store and promoting the application through specific channels, Pace Software aims to reduce the likelihood of users seeking or downloading it from unauthorized sources.

Onboarding

Pace Software maintains a detailed onboard process for the mobile application to ensure that all MPoC requirements are met, including security, privacy, and compliance. Pace Software takes the following steps to ensure the integrity of the onboarding process:

Verification of user identity and verification that all necessary documentation is completed.
Ensure the user's device meets the minimum requirements for running the application, including operating system version and device specifications.
Thorough security and privacy assessment of the device, including a check for root status, jail-breaking, and any other potential vulnerabilities.
Host the application only on Google Play Store and configure the app according to the MPoC requirements.
Provide training to the user on how to use the application securely and how to maintain device security.
Regularly monitor the device and the application for any security or privacy issues and respond accordingly.
Continuously assess and update the onboarding process to ensure that it remains compliant with MPoC requirements.

User Interface Screens

The following screenshots show example screens from the mobile application.

Login Screen

Example of Login Screen

Password Verification Code Screen

Example of Password Verification Code Approval Screen

Payment Terminal Screen

Example of Terminal Screen where user can enter a transaction request.

Review Sale Screens

Example of Review Sale Screen where user can review completed transactions.

\newpage{}

Backend Framework

The system's backend framework is a collection of ASP.NET microservices and APIs that handle all requests from the Mobile Application, providing functionality such as authentication, payment processing, user profile management, and reporting. It uses a microservices architecture, allowing for flexibility and scalability, and it is built on top of the .NET framework, making use of its libraries and tools. The framework also communicates with various external services, such as the HSM, to provide additional functionality, such as encryption key management. Additionally, it utilizes Azure Service Bus for communication and orchestration between the microservices.

Technical details

Programming Languages: The backend framework is primarily built using C# and ASP.NET, which provide a powerful and efficient way to build microservices.

Frameworks and Libraries: The backend framework makes use of various frameworks and libraries such as ASP.NET Core for building web applications, and the Entity Framework for data access and mapping. Additionally, it uses the MediatR library for handling requests and the AutoMapper library for mapping between different object models.

Database: The backend framework uses PostgreSQL as its primary data store, which is a powerful and reliable open-source relational database management system. The Entity Framework is used to interact with the database and provide a simple and efficient way to perform CRUD operations.

Communication: The backend framework uses Azure Service Bus as its primary communication mechanism between the microservices. This allows for a loosely coupled architecture and allows for easier scaling and maintenance.

Encryption: The backend framework uses the same encryption methods as the mobile app, the Advanced Encryption Standard (AES) algorithm with a 256-bit key for data at rest, and Transport Layer Security (TLS) protocol for data in transit.

Diagrams

System Architecture Overview

The Pace Software mobile application uses a microservices-based architecture. The user interacts with the mobile application through the User Interface which sends requests to the Mobile App. The Mobile App then forwards the requests to the API Gateway. The API Gateway acts as the entry point for incoming requests and is responsible for directing them to the appropriate microservices such as Cryptography Service, Profile Service, Client Service, Payment Service and Login Service. These services communicate with each other using a Service Bus, which is a messaging layer that allows them to communicate with a publisher-subscriber pattern. Data is stored in a database and a Cache, and the system is hosted on Azure using Kubernetes Cluster as the container orchestration platform.

Back End Web APIs and Microservices Architecture

The Pace Software public web APIs, that handle all requests from the mobile application, is a serverless, microservices-based architecture. An API Gateway acts as the entry point for incoming requests from the mobile application on the user's Android smartphone or other CoTS device. This API Gateway also referred to as the "Orchestration Service", "orchestrates" incoming requests by parsing the header content of the JSON object and directing the JSON object to the correct microservice, such as Login Service, Payment Service, Cryptography Service, Client Service, and User Profile Service.

Intra-microservice communication is via Azure Service Bus using a publisher-subscriber pattern. Data is stored in a Cache (Redis) and a Database (PostgreSQL). The microservices are containerized using Docker and the system is hosted on an Azure Cloud, using Kubernetes as the container orchestration platform.

Mobile Application Architecture

The system shown in the diagram is a mobile application that uses the Kotlin programming language, a reactive UI and the Agnos EMV L2 Kernel. The kernel has a library, KML library, that orders the mobile application to request a SMK from an external Hardware Security Module (HSM) when a transaction is initiated by the user. The mobile application sends all requests to an API Gateway, which routes the requests to the backend services and returns the responses to the UI. The mobile application also uses a component called zKeyBox, which uses whitebox cryptography to store encryption keys used to encrypt and decrypt the messages in the requests and responses. The zKeyBox stores sensitive data in the local storage, Android Room DB.

Data Flows

The data flow diagrams show how data is passed through the system by the various system elements.

These diagrams refers to different items in the system relevant to encryption and user authentication. The following tables describes these items:

Abbreviation	Name	Description
n/a	API Key	An API key is a unique identifier used to authenticate and authorize access to a RESTful API. It is essentially a secret token that is issued to a user or application developer by the API provider.
IV	Initialization Vector	An initialization vector (IV) is a randomly generated value that is used in conjunction with a cryptographic algorithm to add an extra layer of security to encrypted data. The IV is typically a block of random data that is the same length as the block size of the cipher being used. The purpose of the IV is to ensure that the same plaintext message encrypted with the same key will produce different ciphertexts each time.
gmk	General Message Key	"General Message Keys" (GMK) are encryption keys generated by the HSM that provide packet-level encryption of API messages. The General Message Key is used only for API messages with NO sensitive data. THE GMK is rotated every 30 days or as requested by the user.
smk	Sensitive Message Key	"Sensitive Message Keys" are encryption keys generated by the HSM that provide packet-level encryption of API messages. The SMK is needed to encrypt any message with sensitive data, including PAN, CVV, and trackdata. The SMK (SMK) is rotated after every use, that is, the SMK is used by the client to encrypt the message then again to decrypt the response, then the key is rotated. The user will have a new SMK the next request they make with sensitive data.

Download App, Login, and Onboard New Device

This diagram shows the process of downloading the application, logging in to the mobile application, and arriving at the application's main dashboard screen. The process starts with the user downloading the mobile application and finishes with the user arriving at the dashboard screen.

The user downloads the mobile application from the Google Play Store and enters their phone number and password.
The mobile application sends the user's credentials to the API Gateway, which then authenticates the user.
If the user is authenticated, a one-time password (OTP) is sent to the user's phone number via a third-party service.
The user enters the OTP into the mobile application, which sends it to the API Gateway for validation.
After successful OTP validation, ZKeyBox creates new encryption keys and stores them in the Android Data Storage database.
The mobile application verifies if the user's phone number is linked to a client account by sending a request to the API Gateway, which in turn communicates with the Device Management Service.
If the phone number is linked to a client account, the device is onboarded to the system, and the user can access the home screen and perform transactions.
If the phone number is not linked, the device is added to the system, but the mobile application will have limited functionality until the phone number is linked to a client account.

Send transaction from main dashboard

The diagram shows the process of sending a transaction once the user is logged in with a valid, active device.

The user initiates a transaction. The mobile application requests an encryption key from the API Gateway, which communicates with the Crypto Service and Hardware Security Module (HSM) to obtain the key
The mobile application encrypts sensitive transaction data using the received key and sends the encrypted transaction to the API Gateway.
The API Gateway forwards the transaction request to the Transaction Service, which prepares the request for the third-party payment processor.
The Transaction Service sends the transaction request to the API Gateway, which forwards it to the payment processor.
The payment processor processes the transaction and sends the response back to the API Gateway, which forwards it to the mobile application.

Login and send transaction request via mobile app

This diagram shows the full process of sending a transaction after first downloading the application and logging into the application. The process starts with the user downloading the mobile application and ends with the response from the processor displayed on the user's screen.

The user downloads the mobile application from the Google Play Store and enters their phone number and password.
The mobile application sends the user's credentials to the API Gateway, which then authenticates the user.
If the user is authenticated, a one-time password (OTP) is sent to the user's phone number via a third-party service.
The user enters the OTP into the mobile application, which sends it to the API Gateway for validation.
After successful OTP validation, ZKeyBox creates new encryption keys and stores them in the Android Data Storage database.
The mobile application verifies if the user's phone number is linked to a client account by sending a request to the API Gateway, which in turn communicates with the Device Management Service.
If the phone number is linked to a client account, the device is onboarded to the system, and the user can access the home screen and perform transactions.
If the phone number is not linked, the device is added to the system, but the mobile application will have limited functionality until the phone number is linked to a client account.
Once the phone is onboarded, the user initiates a transaction. The mobile application requests an encryption key from the API Gateway, which communicates with the Crypto Service and Hardware Security Module (HSM) to obtain the key.
The mobile application encrypts sensitive transaction data using the received key and sends the encrypted transaction to the API Gateway.
The API Gateway forwards the transaction request to the Transaction Service, which prepares the request for the third-party payment processor.
The Transaction Service sends the transaction request to the API Gateway, which forwards it to the payment processor.
The payment processor processes the transaction and sends the response back to the API Gateway, which forwards it to the mobile application.

Security and compliance

System security measures

Data protection: The Pace Software system protects sensitive payment data, such as credit card numbers, from unauthorized access, use, disclosure, alteration, or destruction.
Access control: The Pace Software system implements strict access controls and authentication mechanisms, to prevent unauthorized access to sensitive payment data.
Network security: The Pace Software system implements measures to secure network communications, such as encryption and secure socket layer (SSL) certificates, to protect sensitive payment data in transit.
Vulnerability management: The Pace Software system is regularly tested and patched to protect against known vulnerabilities and common attacks.
Incident response: The Pace Software system has an incident response plan in place to quickly detect and respond to security incidents.
Compliance: The Pace Software system is compliant with the Payment Card Industry Data Security Standard (PCI DSS) and other relevant industry standards and regulations.
Monitoring and logging: The Pace Software system has monitoring and logging capabilities to detect and respond to security incidents and maintain an accurate record of system activity.
Physical security: The Pace Software system is physically secure, to prevent unauthorized access to sensitive payment data and systems.
Personnel security: The Pace Software system has personnel security controls in place, such as background checks and security training, to ensure that all personnel has appropriate access to sensitive payment data.

MPoC compliance

Pace Software API microservices have been developed with security as a top priority and have been built to meet the requirements of the Payment Card Industry (PCI) Master Payment Operations Control (MPoC) standard. Our API microservices use industry-standard encryption algorithms for data-in-transit and data-at-rest, to ensure compliance with the PCI MPoC standard, and have been designed with strict access controls and authentication mechanisms, to prevent unauthorized access and protect sensitive payment information, as required by the PCI MPoC standard."

Our API microservices have undergone regular security audits and penetration testing to validate compliance with the PCI MPoC standard and have been developed with a focus on the least privilege principle and have been hardened to protect against common vulnerabilities and attacks, as required by the PCI MPoC standard."

Random Number Generation

The Pace Software system generates secure random numbers using the Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) algorithm. The CSPRNG algorithm is a deterministic random bit generator that generates a sequence of random numbers based on a seed value. The seed value is generated using a combination of hardware-based and software-based sources of entropy, such as the current time, system uptime, and mouse and keyboard events.

The software uses the built-in random number generator provided by the operating system of the deployed platforms, such as Windows Cryptography API (CryptoAPI) on Windows and SecureRandom on Android. These built-in libraries have been thoroughly vetted and are considered secure for cryptographic use.

The CSPRNG algorithm also includes a cryptographic hashing function, such as SHA-256, to ensure that the generated numbers are truly random and cannot be predicted. The generated numbers are then passed through a cryptographic function such as a cryptographic hash function to produce the final output.

Additionally, the software also implements a series of tests such as statistical tests to further ensure that the generated numbers are random and suitable for cryptographic use.

In summary, the MPoC software generates secure random numbers using the CSPRNG algorithm, which combines hardware-based and software-based sources of entropy, cryptographic hashing function, and built-in libraries provided by the operating system of the deployed platforms. The software also implements a series of tests to further ensure that the generated numbers are truly random and suitable for cryptographic use.</

Key Management

The following details important elements of Pace Software Key Management Policy.

Key Generation: The system generates cryptographic keys using approved algorithms, such as AES-256, and stores them in a hardware security module (HSM) for added security. The HSM is a tamper-resistant device that is used to store cryptographic keys, and it is designed to protect the keys from unauthorized access, even in the event of a security breach.

Key Distribution: The system uses a secure key distribution mechanism to distribute the cryptographic keys to the various components of the system, such as the mobile app, the microservices, and the database. The keys are distributed using secure protocols, such as HTTPS, and they are encrypted in transit.

Key Rotation: The system implements a key rotation mechanism that automatically rotates the cryptographic keys regularly, such as every 30 days. This helps to ensure that the keys are not compromised and that the system remains secure.

Key Backup: The system creates multiple backups of the cryptographic keys and stores them in a secure location, such as an HSM. These backups are used to restore the keys in case of a disaster or a security breach.

Key Management Policy: The system's key management policy outlines the procedures for creating, storing, distributing, and rotating cryptographic keys. The policy also defines the roles and responsibilities of the different parties involved in key management, including the key administrator, the key custodian, and the system administrator.

Test and validation

The following are some of the more important testing and validation processes that Pace Software uses to ensure the system meets its requirements and is fit for its intended purpose.

Unit Testing: The system's code is thoroughly unit tested at the component level to ensure that individual components function as intended. This includes testing the microservices, the mobile app, and the APIs.

Integration Testing: The system is integration tested to ensure that all components work together as intended. This includes testing the interactions between the microservices, the mobile app, and the APIs, as well as testing the interactions between the system and any external systems it integrates with, such as payment processors and key management systems.

Functional Testing: The system is functionally tested to ensure that it meets its requirements and is fit for its intended purpose. This includes testing of the system's features, such as user authentication, payment processing, and data management, as well as testing of the system's performance, such as response times and scalability.

User Acceptance Testing (UAT): The system is tested by a group of representative users, to ensure that it is easy to use and meets their needs. This includes testing of the mobile app's usability, and the API's functionality and usability, as well as testing the system's compliance with the MPoC requirement.

Security Testing: The system is security tested to ensure that it is protected against common vulnerabilities, such as injection attacks, cross-site scripting, and data breaches. This includes penetration testing, vulnerability scanning, and code review, as well as testing of the system's compliance with relevant security standards such as PCI DSS.

References

Agnos EMV Level 2 Framework Wiki

Glossary

AES: a widely used symmetric-key encryption algorithm

API: a set of routines, protocols, and tools for building software and applications

ASP.NET: a web framework developed by Microsoft for building web applications

Asymmetric-key encryption: an encryption method in which a public key is used for encryption and a private key is used for decryption.

COTS (Commercial off the Shelf): hardware and software IT products that are ready-made and available for purchase by the general public

Cryptography: the practice of secure communication and data protection

EMV: a global standard for the inter-operation of integrated circuit cards (IC cards or "chip cards") and IC card capable point of sale (POS) terminals and automated teller machines (ATMs)

Hash Function: a mathematical function that takes an input (or 'message') and returns a fixed-size string of characters, which is the 'hash'

Hardware Security Module (HSM): a dedicated, tamper-resistant device that provides a secure environment for the storage and processing of cryptographic keys and other sensitive information

Initialization Vector: an input to a cryptographic primitive being used to provide the initial state

JWT (JSON Web Token): a compact, URL-safe means of representing claims to be transferred between two parties

JSON (JavaScript Object Notation): a lightweight data-interchange format that is easy for humans to read and write and easy for machines to parse and generate

Kotlin: a programming language for the JVM, Android, and the browser that is fully interoperable with Java

KYC: Know Your Customer, a process of verifying the identity of customers

MPoC (Mobile Payments on Contactless): a set of standards that ensure the secure exchange of payment information between mobile devices and point of sale terminals.

PCI DSS (Payment Card Industry Data Security Standard): a set of security standards for organizations that handle credit card information

PKI (Public Key Infrastructure): a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates.

RSA: a widely used public-key algorithm for digital signatures and encryption

REST (Representational State Transfer): an architectural style for building web services

SDK (Software Development Kit): a collection of software development tools in one installable package

SSL/TLS: a security protocol that provides encryption and authentication for network communications

Symmetric-key encryption: an encryption method in which the same key is used for both encryption and decryption

Tokenization: the process of replacing sensitive data with a non-sensitive equivalent referred to as a token, that has no extrinsic or exploitable meaning or value

UI (User Interface): the part of the application that the user interacts with

X.509: a standard that defines the format of public key certificates.

White-box cryptography: Security that prevents the exposure of valuable information by obfuscating the data but also storing it in random data and within the code itself.