rectanglehealth

API Overview

User Guide

Integration Guide

Test Information

Gateway References

Workflows

Flowchart

Rectangle Health Pay - Card Present

Payment

Custom Fields

Rectangle Health Pay - Card Not Present

Payment Encryption

Sale

Void/Refund

Surcharge

Transaction Reporting API

Get Transaction by Transaction ID

Get Transactions by Invoice Number

Get Transactions by Merchant Account Code (MAC)

Get Transactions by Date Range

Card-on-File (CoF) API

Get Card-on-File

Create Card-on-File (CC)

Create Card-on-File (ACH)

Delete Card-on-File

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, reporting, and reconciliation. It provides access to transaction records and related payment information, 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><li class="slate-li " ><div style="position:relative">Merchant Account Code (MAC)</div></li><li class="slate-li " ><div style="position:relative">Date Range and Merchant Account Code (MAC)</div></li></ul><p class="slate-p " >Refer to the individual endpoint documentation for required parameters, supported filters, pagination options, and request/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="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, reporting, and reconciliation. It provides access to transaction records and related payment information, 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, supported filters, pagination options, and request/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 cof reference (a reference ID linking the payment token) 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 Card-on-File (CoF) for securely storing card/bank data</div></li><li class="slate-li " ><div style="position:relative">Retrieve an existing Card-on-File (CoF)</div></li><li class="slate-li " ><div style="position:relative">Delete a stored Card-on-File (CoF) </div></li></ul><p class="slate-p " >Upon successful creation, the API returns a <code class="slate-code">cof_reference</code> and 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 Card-on-File (CoF), both the <code class="slate-code">merchant_account_code</code> and <code class="slate-code">cof_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> (for CC) /  <code class="slate-code">encrypted_bank_data</code> (for ACH) 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 Card-on-File (CoF). </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="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 cof reference (a reference ID linking the payment token) 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 

 that can be used for further transactions. 

To retrieve or delete a Card-on-File (CoF), 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.

 (for ACH) 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 Card-on-File including payment token using the <code class="slate-code">merchant_account_code</code> and <code class="slate-code">cof_reference</code>. Both parameters are required to locate the associated CoF record. </p>

The following example shows how to retrieve a stored Card-on-File including payment token using the 

. Both parameters are required to locate the associated CoF record. 

The media type of the resource being sent or expected, typically set to application/json for this API

Content-Type

HTTP header indicating whether the network connection should be kept open or closed after the completion of the request

Connection

The API key provided to authenticate and authorize the client making the request

x-api-key

A query parameter specifying the merchant’s account identifier used to filter card-on-file results

merchant_account_code

A reference string used to identify and retrieve a specific card-on-file record

cof_reference

A unique identifier representing the stored payment card used for transaction authentication and processing

payment_token

The partially redacted primary account number of the card, displaying only the last four digits for security

masked_pan

The type or brand of the card, such as Visa, MasterCard, or American Express

card_type

A unique identifier assigned to the stored card record within the system

card_identifier

The full name of the individual authorized to use the card on file

account_holder_name

The first line of the cardholder’s billing address

customer_address_line1

The city component of the cardholder’s billing address

customer_city

The state or province component of the cardholder’s billing address

customer_state

The postal code associated with the cardholder's billing address

customer_zip

A key-value object containing additional custom information associated with the card-on-file record

metadata

The merchant's unique account identifier used to filter card-on-file records in the query

A reference string to identify and retrieve a specific card-on-file record

A unique token representing the stored payment card used to securely process transactions

The partially masked account number of the card, displaying only select digits for security purposes

masked_account_number

A key-value map containing custom data associated with the card-on-file record for additional context

<p class="slate-p " >The following example shows how to create a Card-on-File (CoF) 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">cof_reference</code> and <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">cof_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 Card-on-File (CoF) by submitting encrypted card data along with the associated merchant account. 

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

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.

The full name of the individual or entity that holds the account associated with the card.

account_holder

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.

The unique identifier for the merchant account associated with this payment token request.

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

A secure token representing the card information for use in subsequent payment transactions.

The payment card number partially masked for security, showing only the last four digits.

The brand or type of the payment card, such as Visa, MasterCard, or American Express.

A unique identifier assigned to the stored card for reference in subsequent transactions.

The name of the account holder associated with the card-on-file record.

The first line of the cardholder's billing address.

The city component of the customer's billing address as stored in the system.

The state or province component of the customer's billing address.

The postal code component of the customer's billing address as stored in the system.

The card's expiration date in MM/YY format.

expiration_date

A key-value object containing additional information or custom data related to the card-on-file.

<p class="slate-p " >The following example shows how to create a Card-on-File (CoF) by submitting encrypted bank data along with the associated merchant account. </p><p class="slate-p " >The <code class="slate-code">encrypted_bank_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">cof_reference</code> and <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">cof_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><p class="slate-p " ></p>

The following example shows how to create a Card-on-File (CoF) by submitting encrypted bank data along with the associated merchant account. 

The encrypted bank account data securely transmitted for processing the payment

encrypted_bank_data

<p class="slate-p " >The following example shows how to delete a stored Card-on-File (CoF) using the <code class="slate-code">merchant_account_code</code> and <code class="slate-code">cof_reference</code>. Once deleted, both <code class="slate-code">cof_reference</code> and <code class="slate-code">payment_token</code> can no longer be used for future transactions.</p>

The following example shows how to delete a stored Card-on-File (CoF) using the 

 can no longer be used for future transactions.

Specifies the media type of the request body, typically set to application/json for this endpoint

Controls the network connection behavior, such as keep-alive or close, during the API request

The API key provided to authenticate and authorize the request to the card-on-file deletion endpoint

A unique identifier assigned to the merchant account, used to specify which merchant's card-on-file record to delete

The unique reference ID of the card-on-file record to be deleted

An optional object containing additional information or context related to the deletion request

A unique identifier for the merchant account specifying which merchant’s card-on-file record should be deleted

The unique identifier of the card-on-file record targeted for deletion

An optional object containing additional context or custom information related to the deletion request

<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