rectanglehealth

API Overview

User Guide

Integration Guide

Test Information

Workflows

Flowchart

Rectangle Health Pay - Card Present

Payment

Rectangle Health Pay - Card Not Present

Payment Encryption

Sale

Sale via Payment Token

Void/Refund

Partial Void/Refund

Surcharge

Transaction Reporting API

Get Transactions by Invoice Number

Get Transaction by Transaction ID

Card-on-File (CoF) API

Get Payment Token

Create Payment Token

Delete Payment Token

Product Release Notes

API Release Notes

Authentication / Authorization Release Notes

🔔 Subscribe for Updates 🔔

Default

RH API

username

password

authenticationTokenId

tokenPayPrivateKey

Sandbox

Production

<p class="slate-p " >Rectangle Health APIs provide a flexible and secure way to process payments and manage transaction data across different payment scenarioes. Whether you&apos;re handling in-person payments through terminals or processing transactions online, our APIs are designed to support a seamless integration experience. </p><p class="slate-p " >Our platform offers dedicated APIs for both Card Present (CP) and Card Not Present (CNP) transactions, each tailored to its specific use case. In addition, the Transaction Reporting API and Card-on-File (CoF) API extend your ability to access transaction insights and manage stored payment methods. </p><p class="slate-p " >Explore the sections below to learn more about each API and how to integrate with Rectangle Health.</p><p class="slate-p " ></p><h3 class="slate-h3 " >Rectangle Health Pay - Card Present</h3><p class="slate-p " >The Rectangle Health Pay - Card Present API supports in-person payment processing on supported PAX terminal devices. The API enables merchants to initiate standard sale and surcharge-enabled sale transactions by submitting a request to the gateway, which initializes the terminal to accept a card payment. </p><p class="slate-p " >A dedicated Rectangle Health payment application must be installed on the terminal device, replacing the legacy application. This application manages transaction processing and communication with the gateway, ensuring secure and streamlined payment handling at the point of sale. </p><p class="slate-p " ></p><h3 class="slate-h3 " >Rectangle Health Pay - Card Not Present </h3><p class="slate-p " >The Rectangle Health Pay - Card Not Present API provides a secure and flexible way to process transactions without a physical card present. The API supports essential transaction workflows, including sale, void/refund, and partial void/refund. </p><p class="slate-p " >Sensitive payment data is secured through client-side encryption, while API key-based authentication ensures that all requests are properly authorized. This approach enables PCI-compliant integrations with minimal exposure to cardholder data. </p><p class="slate-p " ></p><h3 class="slate-h3 " >Transaction Reporting API </h3><p class="slate-p " >The Transaction Reporting API allows a technology partner to offer their users access to transaction data for reporting and reconciliation purposes. This API enables retrieval of transaction history to support financial analysis and reporting workflows. </p><p class="slate-p " ></p><h3 class="slate-h3 " >Card-on-File (CoF) API </h3><p class="slate-p " >The Card-on-File (CoF) API enables secure storage and management of customer payment information through tokenization. Sensitive payment data is replaced with a reusable payment token, allowing stored payment methods to be referenced without exposing actual card details.</p><p class="slate-p " >Businesses can create, retrieve, and delete stored payment methods, supporting use cases such as faster checkout experiences and recurring or repeat payments. The API ensures compliance with PCI DSS while providing a secure way to store and manage sensitive payment details.</p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

Rectangle Health APIs provide a flexible and secure way to process payments and manage transaction data across different payment scenarioes. Whether you're handling in-person payments through terminals or processing transactions online, our APIs are designed to support a seamless integration experience. 

Our platform offers dedicated APIs for both Card Present (CP) and Card Not Present (CNP) transactions, each tailored to its specific use case. In addition, the Transaction Reporting API and Card-on-File (CoF) API extend your ability to access transaction insights and manage stored payment methods. 

Explore the sections below to learn more about each API and how to integrate with Rectangle Health.

The Rectangle Health Pay - Card Present API supports in-person payment processing on supported PAX terminal devices. The API enables merchants to initiate standard sale and surcharge-enabled sale transactions by submitting a request to the gateway, which initializes the terminal to accept a card payment. 

A dedicated Rectangle Health payment application must be installed on the terminal device, replacing the legacy application. This application manages transaction processing and communication with the gateway, ensuring secure and streamlined payment handling at the point of sale. 

The Rectangle Health Pay - Card Not Present API provides a secure and flexible way to process transactions without a physical card present. The API supports essential transaction workflows, including sale, void/refund, and partial void/refund. 

Sensitive payment data is secured through client-side encryption, while API key-based authentication ensures that all requests are properly authorized. This approach enables PCI-compliant integrations with minimal exposure to cardholder data. 

The Transaction Reporting API allows a technology partner to offer their users access to transaction data for reporting and reconciliation purposes. This API enables retrieval of transaction history to support financial analysis and reporting workflows. 

The Card-on-File (CoF) API enables secure storage and management of customer payment information through tokenization. Sensitive payment data is replaced with a reusable payment token, allowing stored payment methods to be referenced without exposing actual card details.

Businesses can create, retrieve, and delete stored payment methods, supporting use cases such as faster checkout experiences and recurring or repeat payments. The API ensures compliance with PCI DSS while providing a secure way to store and manage sensitive payment details.

<p class="slate-p " >The User Guide section provides comprehensive instructions and guidelines for effectively utilizing the APIs within the project. Users can learn how to navigate the API&apos;s functionalities, understand its various features, and optimize their integration process for seamless operations. This section serves as a valuable resource for developers seeking clarity and guidance on leveraging the APIs to its full potential.</p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

The User Guide section provides comprehensive instructions and guidelines for effectively utilizing the APIs within the project. Users can learn how to navigate the API's functionalities, understand its various features, and optimize their integration process for seamless operations. This section serves as a valuable resource for developers seeking clarity and guidance on leveraging the APIs to its full potential.

<p class="slate-p " ></p><h2 class="slate-h2 " >Overview</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The Rectangle Health Pay - Card Present section enables seamless processing of card-present transactions using supported PAX terminals. Users can securely authorize and capture payments directly at the ponit of sale, ensuring efficient and reliable card-present payment handling.</p><p class="slate-p " ></p><h2 class="slate-h2 " >Authentication Information</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >To process card-present transactions, the terminal must be onboarded and configured in the Rectangle Health system with the corresponding gateway information. </p><p class="slate-p " >Each payment request must include the device serial number. The platform uses this value to identify the terminal device and determine the associated merchant account. </p><p class="slate-p " >Once the request is received, the gateway routes the transaction to the specified terminal, which then initiates the payment flow for customer interaction and processing. </p><p class="slate-p " ></p><h2 class="slate-h2 " >Terminal Information</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >(Supported PAX Series)</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">PAX A77</div></li><li class="slate-li " ><div style="position:relative">PAX A920 Max</div></li><li class="slate-li " ><div style="position:relative">PAX A35</div></li></ul><p class="slate-p " ></p><h2 class="slate-h2 " >Support</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >If you have any issues or questions, please reach out to Integration (integration@rectanglehealth.com).</p><p class="slate-p " ></p>

The Rectangle Health Pay - Card Present section enables seamless processing of card-present transactions using supported PAX terminals. Users can securely authorize and capture payments directly at the ponit of sale, ensuring efficient and reliable card-present payment handling.

To process card-present transactions, the terminal must be onboarded and configured in the Rectangle Health system with the corresponding gateway information. 

Each payment request must include the device serial number. The platform uses this value to identify the terminal device and determine the associated merchant account. 

Once the request is received, the gateway routes the transaction to the specified terminal, which then initiates the payment flow for customer interaction and processing. 

If you have any issues or questions, please reach out to Integration (integration@rectanglehealth.com).

<p class="slate-p " ></p><h2 class="slate-h2 " >Overview</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The Rectangle Health Pay - Card Not Present section enables secure processing of transactions where the card is not physically present, such as online or virtual payments. </p><p class="slate-p " >This API supports core transaction operations including sale, void/refund, and partial void/refund. It is designed to work with encrypted payment data, allowing merchants to securely submit card information while maintaining PCI compliance. </p><p class="slate-p " ></p><h2 class="slate-h2 " >Authentication Information</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >Card-not-present transactions require API key-based authentication to authorize requests. </p><p class="slate-p " >Each request must include a valid API key in the request headers. This key identifies the calling application and ensures that only authorized clients can access the API.</p><p class="slate-p " >The merchant account is specified within the request to ensure the transaction is processed under the correct account. </p><p class="slate-p " ></p><h2 class="slate-h2 " >Encryption Requirements</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >Sensitive payment data must be encrypted prior to submission using the provided client-side encryption method. This ensures that cardholder data is securely transmitted and not exposed within the merchant&apos;s environment. </p><div style="width:100%;
	min-width:100%;" class="callout-widget" data-type=info ><div class="callout-icon"><svg width="20" height="20" viewBox="0 0 20 20" fill="none" xmlns="http://www.w3.org/2000/svg"><path d="M10.0628 14.1676C10.2434 14.1676 10.3927 14.1086 10.5107 13.9905C10.6288 13.8725 10.6878 13.7232 10.6878 13.5426V9.77177C10.6878 9.6051 10.6253 9.46274 10.5003 9.34469C10.3753 9.22663 10.2295 9.1676 10.0628 9.1676C9.88227 9.1676 9.73296 9.22663 9.61491 9.34469C9.49685 9.46274 9.43783 9.61205 9.43783 9.7926V13.5634C9.43783 13.7301 9.50033 13.8725 9.62533 13.9905C9.75033 14.1086 9.89616 14.1676 10.0628 14.1676ZM10.0003 7.62594C10.1948 7.62594 10.358 7.56344 10.4899 7.43844C10.6219 7.31344 10.6878 7.15371 10.6878 6.95927C10.6878 6.76482 10.6219 6.59816 10.4899 6.45927C10.358 6.32038 10.1948 6.25094 10.0003 6.25094C9.80588 6.25094 9.64269 6.32038 9.51074 6.45927C9.3788 6.59816 9.31283 6.76482 9.31283 6.95927C9.31283 7.15371 9.3788 7.31344 9.51074 7.43844C9.64269 7.56344 9.80588 7.62594 10.0003 7.62594ZM10.0003 18.3343C8.81977 18.3343 7.72255 18.1225 6.70866 17.6989C5.69477 17.2752 4.81283 16.6884 4.06283 15.9384C3.31283 15.1884 2.72602 14.3065 2.30241 13.2926C1.8788 12.2787 1.66699 11.1815 1.66699 10.0009C1.66699 8.83427 1.8788 7.74399 2.30241 6.7301C2.72602 5.71621 3.31283 4.83427 4.06283 4.08427C4.81283 3.33427 5.69477 2.74399 6.70866 2.31344C7.72255 1.88288 8.81977 1.6676 10.0003 1.6676C11.167 1.6676 12.2573 1.88288 13.2712 2.31344C14.285 2.74399 15.167 3.33427 15.917 4.08427C16.667 4.83427 17.2573 5.71621 17.6878 6.7301C18.1184 7.74399 18.3337 8.83427 18.3337 10.0009C18.3337 11.1815 18.1184 12.2787 17.6878 13.2926C17.2573 14.3065 16.667 15.1884 15.917 15.9384C15.167 16.6884 14.285 17.2752 13.2712 17.6989C12.2573 18.1225 11.167 18.3343 10.0003 18.3343ZM10.0003 17.0843C11.9448 17.0843 13.6114 16.3898 15.0003 15.0009C16.3892 13.612 17.0837 11.9454 17.0837 10.0009C17.0837 8.05649 16.3892 6.38982 15.0003 5.00094C13.6114 3.61205 11.9448 2.9176 10.0003 2.9176C8.05588 2.9176 6.38921 3.61205 5.00033 5.00094C3.61144 6.38982 2.91699 8.05649 2.91699 10.0009C2.91699 11.9454 3.61144 13.612 5.00033 15.0009C6.38921 16.3898 8.05588 17.0843 10.0003 17.0843Z" fill="#3960B4"></path></svg></div><div ><p class="slate-p " >Encryption requirements apply only to endpoints that accept sensitive payment data, such as Sale endpoint. </p></div></div><p class="slate-p " ></p><h2 class="slate-h2 " >Support</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >If you have any issues or questions, please reach out to Integration (integration@rectanglehealth.com).</p><p class="slate-p " ></p>

The Rectangle Health Pay - Card Not Present section enables secure processing of transactions where the card is not physically present, such as online or virtual payments. 

This API supports core transaction operations including sale, void/refund, and partial void/refund. It is designed to work with encrypted payment data, allowing merchants to securely submit card information while maintaining PCI compliance. 

Card-not-present transactions require API key-based authentication to authorize requests. 

Each request must include a valid API key in the request headers. This key identifies the calling application and ensures that only authorized clients can access the API.

The merchant account is specified within the request to ensure the transaction is processed under the correct account. 

Sensitive payment data must be encrypted prior to submission using the provided client-side encryption method. This ensures that cardholder data is securely transmitted and not exposed within the merchant's environment. 

<p class="slate-p " ></p><h2 class="slate-h2 " >Overview</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The Transaction Reporting API enables users to retrieve detailed transaction data for financial analysis and reconciliation. It provides access to transaction records, helping businesses monitor payment activity and generate accurate reports. </p><p class="slate-p " >This API supports retrieving transactions using the following methods: </p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Invoice Number</div></li><li class="slate-li " ><div style="position:relative">Transaction ID</div></li></ul><p class="slate-p " >Refer to the individual endpoint documentation for required parameters, along with request and response examples. </p><p class="slate-p " ></p><h2 class="slate-h2 " >Authentication Information</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The Transaction Reporting API uses a simple API key-based authentication method to authorize requests.</p><p class="slate-p " >All API requests must include a valid API key in the request headers. This key uniquely identifies your account and ensures that only authorized clients can access the API. </p><p class="slate-p " ></p><h2 class="slate-h2 " >Support</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >If you have any issues or questions, please reach out to Integration (<a href="https://mailto:integration@rectanglehealth.com" target="">integration@rectanglehealth.com</a>).</p><p class="slate-p " ></p><p class="slate-p " ></p><h4 class="slate-h4 " ></h4><p class="slate-p " ></p>

The Transaction Reporting API enables users to retrieve detailed transaction data for financial analysis and reconciliation. It provides access to transaction records, helping businesses monitor payment activity and generate accurate reports. 

This API supports retrieving transactions using the following methods: 

Refer to the individual endpoint documentation for required parameters, along with request and response examples. 

The Transaction Reporting API uses a simple API key-based authentication method to authorize requests.

All API requests must include a valid API key in the request headers. This key uniquely identifies your account and ensures that only authorized clients can access the API. 

If you have any issues or questions, please reach out to Integration (

<p class="slate-p " ></p><h2 class="slate-h2 " >Overview</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The Card-on-File (CoF) API enables users to securely store and manage payment information for future use. It allows businesses to create reusable payment tokens that represent stored card data, eliminating the need to collect card details for each transaction. </p><p class="slate-p " >This API supports the following operations: </p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Create a payment token for securely storing card data</div></li><li class="slate-li " ><div style="position:relative">Retrieve an existing payment token</div></li><li class="slate-li " ><div style="position:relative">Delete a stored payment token </div></li></ul><p class="slate-p " >Upon successful creation, the APi returns a unique <code class="slate-code">payment_token</code> that can be used for further transactions. </p><p class="slate-p " >To retrieve or delete a payment token, both the <code class="slate-code">merchant_account_code</code> and <code class="slate-code">token_reference</code> are required. Clients should store these values securely, as they are necessary for managing stored payment data. </p><p class="slate-p " ></p><h2 class="slate-h2 " >Authentication Information</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The Card-on-File API uses API key-based authentication to authorize requests.</p><p class="slate-p " >All API requests must include a valid API key in the request headers. This key uniquely identifies your account and ensures that only authorized clients can access the API. </p><p class="slate-p " ></p><h2 class="slate-h2 " >Encryption Requirements </h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The <code class="slate-code">encrypted_card_data</code> field must be generated using the client-side encryption method described in the <a href="69c2ce4fc4a3401439dc6c53/69c411a51ed373df7c803aa2" target="_blank">Payment Encryption</a>. </p><div style="width:100%;
	min-width:100%;" class="callout-widget" data-type=info ><div class="callout-icon"><svg width="20" height="20" viewBox="0 0 20 20" fill="none" xmlns="http://www.w3.org/2000/svg"><path d="M10.0628 14.1676C10.2434 14.1676 10.3927 14.1086 10.5107 13.9905C10.6288 13.8725 10.6878 13.7232 10.6878 13.5426V9.77177C10.6878 9.6051 10.6253 9.46274 10.5003 9.34469C10.3753 9.22663 10.2295 9.1676 10.0628 9.1676C9.88227 9.1676 9.73296 9.22663 9.61491 9.34469C9.49685 9.46274 9.43783 9.61205 9.43783 9.7926V13.5634C9.43783 13.7301 9.50033 13.8725 9.62533 13.9905C9.75033 14.1086 9.89616 14.1676 10.0628 14.1676ZM10.0003 7.62594C10.1948 7.62594 10.358 7.56344 10.4899 7.43844C10.6219 7.31344 10.6878 7.15371 10.6878 6.95927C10.6878 6.76482 10.6219 6.59816 10.4899 6.45927C10.358 6.32038 10.1948 6.25094 10.0003 6.25094C9.80588 6.25094 9.64269 6.32038 9.51074 6.45927C9.3788 6.59816 9.31283 6.76482 9.31283 6.95927C9.31283 7.15371 9.3788 7.31344 9.51074 7.43844C9.64269 7.56344 9.80588 7.62594 10.0003 7.62594ZM10.0003 18.3343C8.81977 18.3343 7.72255 18.1225 6.70866 17.6989C5.69477 17.2752 4.81283 16.6884 4.06283 15.9384C3.31283 15.1884 2.72602 14.3065 2.30241 13.2926C1.8788 12.2787 1.66699 11.1815 1.66699 10.0009C1.66699 8.83427 1.8788 7.74399 2.30241 6.7301C2.72602 5.71621 3.31283 4.83427 4.06283 4.08427C4.81283 3.33427 5.69477 2.74399 6.70866 2.31344C7.72255 1.88288 8.81977 1.6676 10.0003 1.6676C11.167 1.6676 12.2573 1.88288 13.2712 2.31344C14.285 2.74399 15.167 3.33427 15.917 4.08427C16.667 4.83427 17.2573 5.71621 17.6878 6.7301C18.1184 7.74399 18.3337 8.83427 18.3337 10.0009C18.3337 11.1815 18.1184 12.2787 17.6878 13.2926C17.2573 14.3065 16.667 15.1884 15.917 15.9384C15.167 16.6884 14.285 17.2752 13.2712 17.6989C12.2573 18.1225 11.167 18.3343 10.0003 18.3343ZM10.0003 17.0843C11.9448 17.0843 13.6114 16.3898 15.0003 15.0009C16.3892 13.612 17.0837 11.9454 17.0837 10.0009C17.0837 8.05649 16.3892 6.38982 15.0003 5.00094C13.6114 3.61205 11.9448 2.9176 10.0003 2.9176C8.05588 2.9176 6.38921 3.61205 5.00033 5.00094C3.61144 6.38982 2.91699 8.05649 2.91699 10.0009C2.91699 11.9454 3.61144 13.612 5.00033 15.0009C6.38921 16.3898 8.05588 17.0843 10.0003 17.0843Z" fill="#3960B4"></path></svg></div><div ><p class="slate-p " >Encryption requirements apply only to endpoints that accept sensitive payment data, such as Create Payment Token. </p></div></div><p class="slate-p " ></p><h2 class="slate-h2 " >Support</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >If you have any issues or questions, please reach out to Integration (<a href="https://mailto:integration@rectanglehealth.com" target="">integration@rectanglehealth.com</a>).</p><p class="slate-p " ></p>

The Card-on-File (CoF) API enables users to securely store and manage payment information for future use. It allows businesses to create reusable payment tokens that represent stored card data, eliminating the need to collect card details for each transaction. 

This API supports the following operations: 

Upon successful creation, the APi returns a unique 

 that can be used for further transactions. 

To retrieve or delete a payment token, both the 

 are required. Clients should store these values securely, as they are necessary for managing stored payment data. 

The Card-on-File API uses API key-based authentication to authorize requests.

 field must be generated using the client-side encryption method described in the 

<p class="slate-p " >The following example shows how to retrieve a stored payment token using the <code class="slate-code">merchant_account_code</code> and <code class="slate-code">token_reference</code>. Both parameters are required to locate the associated token. </p>

The following example shows how to retrieve a stored payment token using the 

. Both parameters are required to locate the associated token. 

Content-Type

Connection

x-api-key

merchant_account_code

token_reference

payment_token

masked_pan

metadata

<p class="slate-p " >The following example shows how to create a payment token by submitting encrypted card data along with the associated merchant account. </p><p class="slate-p " >The <code class="slate-code">encrypted_card_data</code> field must be generated using the client-side encryption method described in the <a href="69c2ce4fc4a3401439dc6c53/69c411a51ed373df7c803aa2" target="_blank">Payment Encryption</a>. </p><p class="slate-p " >This request securely stores the card information and returns a reusable <code class="slate-code">payment_token</code> for future transactions.</p><div style="width:100%;
	min-width:100%;" class="callout-widget" data-type=info ><div class="callout-icon"><svg width="20" height="20" viewBox="0 0 20 20" fill="none" xmlns="http://www.w3.org/2000/svg"><path d="M10.0628 14.1676C10.2434 14.1676 10.3927 14.1086 10.5107 13.9905C10.6288 13.8725 10.6878 13.7232 10.6878 13.5426V9.77177C10.6878 9.6051 10.6253 9.46274 10.5003 9.34469C10.3753 9.22663 10.2295 9.1676 10.0628 9.1676C9.88227 9.1676 9.73296 9.22663 9.61491 9.34469C9.49685 9.46274 9.43783 9.61205 9.43783 9.7926V13.5634C9.43783 13.7301 9.50033 13.8725 9.62533 13.9905C9.75033 14.1086 9.89616 14.1676 10.0628 14.1676ZM10.0003 7.62594C10.1948 7.62594 10.358 7.56344 10.4899 7.43844C10.6219 7.31344 10.6878 7.15371 10.6878 6.95927C10.6878 6.76482 10.6219 6.59816 10.4899 6.45927C10.358 6.32038 10.1948 6.25094 10.0003 6.25094C9.80588 6.25094 9.64269 6.32038 9.51074 6.45927C9.3788 6.59816 9.31283 6.76482 9.31283 6.95927C9.31283 7.15371 9.3788 7.31344 9.51074 7.43844C9.64269 7.56344 9.80588 7.62594 10.0003 7.62594ZM10.0003 18.3343C8.81977 18.3343 7.72255 18.1225 6.70866 17.6989C5.69477 17.2752 4.81283 16.6884 4.06283 15.9384C3.31283 15.1884 2.72602 14.3065 2.30241 13.2926C1.8788 12.2787 1.66699 11.1815 1.66699 10.0009C1.66699 8.83427 1.8788 7.74399 2.30241 6.7301C2.72602 5.71621 3.31283 4.83427 4.06283 4.08427C4.81283 3.33427 5.69477 2.74399 6.70866 2.31344C7.72255 1.88288 8.81977 1.6676 10.0003 1.6676C11.167 1.6676 12.2573 1.88288 13.2712 2.31344C14.285 2.74399 15.167 3.33427 15.917 4.08427C16.667 4.83427 17.2573 5.71621 17.6878 6.7301C18.1184 7.74399 18.3337 8.83427 18.3337 10.0009C18.3337 11.1815 18.1184 12.2787 17.6878 13.2926C17.2573 14.3065 16.667 15.1884 15.917 15.9384C15.167 16.6884 14.285 17.2752 13.2712 17.6989C12.2573 18.1225 11.167 18.3343 10.0003 18.3343ZM10.0003 17.0843C11.9448 17.0843 13.6114 16.3898 15.0003 15.0009C16.3892 13.612 17.0837 11.9454 17.0837 10.0009C17.0837 8.05649 16.3892 6.38982 15.0003 5.00094C13.6114 3.61205 11.9448 2.9176 10.0003 2.9176C8.05588 2.9176 6.38921 3.61205 5.00033 5.00094C3.61144 6.38982 2.91699 8.05649 2.91699 10.0009C2.91699 11.9454 3.61144 13.612 5.00033 15.0009C6.38921 16.3898 8.05588 17.0843 10.0003 17.0843Z" fill="#3960B4"></path></svg></div><div ><p class="slate-p " >If <code class="slate-code">token_reference</code> is not provided, it will be automatically generated by the system and returned in the resposne.</p></div></div><p class="slate-p " ></p>

The following example shows how to create a payment token by submitting encrypted card data along with the associated merchant account. 

This request securely stores the card information and returns a reusable 

Securely encrypted card information containing the card number, expiration date, and CVV required to generate the payment token.

encrypted_card_data

The unique identifier for the merchant account linked to this payment token request.

A unique reference ID linking the payment token to the original payment request; if omitted, the system generates one automatically.

Indicates the media type of the request payload, typically 'application/json' when sending JSON-formatted data.

Specifies the desired HTTP connection behavior, such as 'keep-alive' to reuse connections or 'close' to terminate after the response.

The API key used to authenticate the request and authorize access to the payment token creation endpoint.

<p class="slate-p " >The following example shows how to delete a stored payment token using the <code class="slate-code">merchant_account_code</code> and <code class="slate-code">token_reference</code>. Once deleted, the token can no longer be used for future transactions.</p>

The following example shows how to delete a stored payment token using the 

. Once deleted, the token can no longer be used for future transactions.

<p class="slate-p " >Manage and retrieve detailed release notes for products within your RH API integration. This section enables you to access the latest updates, track changes across versions, and stay informed about new features or fixes to ensure seamless product maintenance and communication.</p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

Manage and retrieve detailed release notes for products within your RH API integration. This section enables you to access the latest updates, track changes across versions, and stay informed about new features or fixes to ensure seamless product maintenance and communication.

Sections