# Mastercard Processing Core APIs source: https://developer.mastercard.com/mastercard-processing-core/documentation/index.md ## Overview {#overview} Mastercard Processing offers modern, scalable, and configurable card processing solutions to fintech companies and financial institutions. This program supports a wide range of consumer and commercial payment products. Our processing services are available to issuers through Open Application Programming Interfaces (APIs), allowing them to build [Digital First](https://developer.mastercard.com/solutions/digital-first/) card programs and secure payment instruments for cardholders. ## Glossary and Conventions {#glossary-and-conventions} ### Glossary {#glossary} The glossary explains the various terms and definitions, and the acronyms used throughout this documentation. | **Term** | **Definition** | |------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | ABU | Automated Billing Updater | | API | Application Programming Interface | | ATM | The automated teller machine is a cash machine. | | BIN | Bank Identification Number | | Cardholder | An individual who is the card user is usually also the card owner. | | CBS | The Core Banking System is the issuer's server. | | CMS | Card Management System | | CVC2/CVV2 | Card Verification Code (Mastercard) or Card Verification Value (Visa). It is a unique number linked to each card and printed on the physical card. It is shown in the app when a card is virtual and required during online payments. Number 2 is related to EMV technology as CVC1/CVV1 is a number stored on a magnetic stripe. | | EMV | Europay/Mastercard/Visa is the technical standard for card payments. | | EMV Chip | The microprocessor mounted on a card that provides high security and an extensive capacity according to string data. The chip exchanges messages with POS devices or ATMs. | | EMV script | An encrypted message exchanged between a card and a payment ecosystem. | | GDPR | General Data Protection Regulation is a European Union law that regulates data protection and privacy. | | Issuer | The institution, bank, or fintech that issues a card. | | JSON | JavaScript Object Notation | | JWE | JSON Web Encryption | | MP | Mastercard Processing is a processor. | | operationId | It is a unique name for a particular API operation. It is usually in the form of text expressing the name of an operation (for example, `createCard`). | | OAS | The OpenAPI Specification is the documentation of an API constructed by the Open API 3.0 standard. | | PAN | Primary Account Number | | Personalization bureau | It is a company that produces physical cards and is responsible for keeping stock of plastic, embossing data on the plastic, assembling EMV Chips and uploading data onto them, and sending cards to cardholders. | | PGP | Pretty Good Privacy | | Physical card | It is a plastic card with an EMV Chip. | | PIN | Personal Identification Number | | PIN block | It is the encrypted message used to transport the PIN value. | | POS | Point of Sale | | PCI DSS | Payment Card Industry Data Security Standard | | Private Key | It is the RSA key required to decrypt messages in asymmetric key encryption. | | Processor | It is a company providing services for issuers related to card issuance, card management, and processing transactions. | | Public Key | It is the RSA key required to encrypt messages in asymmetric key encryption. | | RSA | Rivest-Shamir-Adleman is the cryptosystem used for the asymmetric encryption of sensitive data transmitted between the issuer and Mastercard Processing API. | | SFTP | Secure File Transfer Protocol | | Smart card | It is a card with an EMV Chip. | | Smart card applet | It is the software on an EMV Chip that is responsible for storing and processing payment data. | | UI | User interface | | Virtual card | It is a card presented in digital form. It contains the same data as the physical card. It is accessed using the issuer's application but can be tokenized and send to other apps. For example, GooglePay enables online payments. After tokenization, when linked to a proper device (mobile phone, watch, or fob), it enables contactless payments on POS terminals. | | ZPK | The Zone PIN Key is used for the symmetric encryption of the PIN block transmitted between the issuer and Mastercard Processing API. | ### Formatting Conventions {#formatting-conventions} We use plain text names for our system objects (for example, account contract). For technical descriptions, we frame words in adherence to the OpenAPI Specification (OAS) naming conventions (for example, `AccountContract`). Framed words can refer to: * API objects: `Client`. * Field names required in API requests: `lastName`. * Defined values you put into API requests or receive in API responses: `RENEW_D`. Some examples of non-predefined values are in plain text (for example, 'Smith'). * API methods and operationIds: `PUT`, `reissueCard`. * Actors: issuer, processor, payment network, personalization bureau, and cardholder are in lower-case letters. ### REST Naming Conventions {#rest-naming-conventions} | **Term** | **Definition** | |-------------|----------------------------------------------------------------------------------------------------------| | method | An HTTP request method, such as `POST`, `GET`, `PUT`, or `PATCH`. | | operation | A specific procedure that is invoked on an object using a method. | | endpoint | A path or address that the API exposes for your requests. A single path can support multiple operations. | | operationId | A unique name used to identify a specific operation (for example, `reissueCard`). | The Mastercard Processing API specifications use the following case format: | Term | Case | Example | |------------------|------------------------|----------------------------------------------| | Property names | camelCase | clientNumber | | Path parameters | snake_case | client_id | | Query parameters | snake_case | authorization_filter_mode in getTransactions | | Header names | Hyphenated-Pascal-Case | Customer-Public-Rsa-Key in getPin | | Path segments | kebab-case | /transaction-documents | ## How It Works {#how-it-works} ![](https://static.developer.mastercard.com/content/mastercard-processing-core/uploads/processing_3.png) Mastercard Processing services are available through RESTful Open APIs that allow issuers to build modern payment solutions and design stellar user experiences. The APIs cover the entire product lifecycle. It starts from setting up a client and address, to creating accounts and ordering a card that can be instantly tokenized. Many mobile PAYs and wearables are supported, including Apple, Google, Samsung, Xiaomi, Fitbit, Garmin, Swatch, Card on File, and issuer Wallet (HCE). [Digital First](https://developer.mastercard.com/solutions/digital-first/) cards can be issued with a physical option. Multiple physical cards and designs are available, including various shapes and materials such as platinum, metal, and eco-friendly materials. The APIs support the full account, card, and token lifecycle, including card activation, temporary blocking, usage limits and spending controls, and other automatic events. The APIs can also be leveraged throughout the transaction lifecycle, from authorization through transaction clearing, dispute management, and fraud prevention rules management. The APIs can also be used to manage credit card and installment loan lifecycles, including payments, funds transfer, transaction history and statements, direct debits, account delinquency, and more. Several operations support various aspects of card products and value-added services. Note: For your convenience, the Mastercard Processing APIs has been divided into smaller logical parts (for example Core APIs, Digital APIs, Dispute APIs, and so on). Each part has a separate specification and technical documentation. In this documentation, Mastercard Processing Core APIs are described. Mastercard Processing Core APIs cover a set of APIs used for any card product (prepaid, debit, credit, or commercial) management, such as: * Create objects in the Mastercard Processing Customer Management System (CMS), including client, account contract, card contract, and basic setups. * Retrieve and update data related to clients, their accounts, and cards. * Issue, renew, or replace virtual and physical cards. * Activate and change cards status. * Manage usage limits. * Set, verify, or retrieve a PIN for the card. * Manage transactions and fees. * Manage and retrieve various data from the CMS. ## Getting Started {#getting-started} Before issuing cards with Mastercard Processing APIs, you must fulfill the requirements. The following diagram illustrates the simplified process of physical card issuance. When you set up a relationship with a payment network for step 1 (in this example, Mastercard Scheme), remember that we also support Visa projects. When you start cooperation with a processor for step 2, the processor in reference is Mastercard Processing. ![](https://static.developer.mastercard.com/content/mastercard-processing-core/uploads/processing_4.png) 1. Set up a Mastercard Scheme project: You must obtain a Mastercard license and have a signed agreement. 2. Set up a project with a payment processor (in this example, with Mastercard Processing): After you sign the contract, the onboarding process requires the following actions in the Mastercard Processing Card Management System (CMS): * Define which product will be used: credit, debit, prepaid; types of limits; and currency. * Choose parameters to define how the API operations will work. 3. Initiate the actual card production using API operations: The personalization bureau must be involved in the physical card production process. Mastercard Processing APIs allow you to create objects and put, retrieve, and update data while managing the [card lifecycle](https://developer.mastercard.com/mastercard-processing-core/documentation/guides/card-lifecycle/index.md). The API Sandbox provides a demo of what to expect even before you contact Mastercard Processing. Try it, customize it to your needs, and [contact us](https://developer.mastercard.com/support/) to share your experience. ## Next Steps {#next-steps} * Review the [Quick Start Guide](https://developer.mastercard.com/platform/documentation/getting-started-with-mastercard-apis/quick-start-guide/) to learn how to use the Mastercard Developers platform. * See [API Basics](https://developer.mastercard.com/mastercard-processing-core/documentation/api-basics-section/index.md) to learn more about authentication and encryption. * See the [Guides](https://developer.mastercard.com/mastercard-processing-core/documentation/guides/index.md) to learn about how the Card Management System works. * Review the [Use Cases](https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/index.md), their implementations, and sequence diagrams. * Use the [API Reference](https://developer.mastercard.com/mastercard-processing-core/documentation/api-reference/index.md) to review the OpenAPI Specification and execute each API endpoint. * Review the [Error Codes](https://developer.mastercard.com/mastercard-processing-core/documentation/code-and-formats/index.md) and the formats that we use. * Review [Support](https://developer.mastercard.com/mastercard-processing-core/documentation/support/index.md) to find answers to questions and get technical support.