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 " >This script leverages client-side encryption of sensitive payment data before transmission to the server. It ensures that cardholder information is protected during transit by applying encryption algorithms within a secure browser-based environment. </p><p class="slate-p " >The embedded payment form supports custom styling via CSS, allowing integrators to align the user interface with their application&apos;s design. When applying custom styles, care should be taken to preserve usability, accessibility, and the integrity of required payment fields. </p><p class="slate-p " >Additionally, implementers should avoid modifying or interfering with the underlying payment logic and ensure that all interactions occur within the secure iframe context. </p><div class="code-block-wrapper"  style="width:100%;min-width:100%" ><div class="code-block-header">HTML</div><pre class="slate-CodeBlockElement slate-code_block"><textarea id="publishedPageCodeblock" style="display:none !important; visibility: hidden; opacity: 0; width: 1px; height: 1px;" type="hidden">&lt;!doctype html&gt;
&lt;html lang=&quot;en&quot;&gt;
&lt;head&gt;
    &lt;meta charset=&quot;utf-8&quot; /&gt;
    &lt;title&gt;CNP-Encryption-Example&lt;/title&gt;
    &lt;meta name=&quot;viewport&quot; content=&quot;width=device-width, initial-scale=1&quot; /&gt;
&lt;/head&gt;
&lt;body&gt;
    &lt;h1&gt;CNP Encryption Example&lt;/h1&gt;
    &lt;iframe
        id=&quot;payment-frame&quot;
        srcdoc=&#39;&lt;!doctype html&gt;
&lt;html lang=&quot;en&quot;&gt;
&lt;head&gt;
    &lt;meta charset=&quot;utf-8&quot;&gt;
    &lt;meta name=&quot;viewport&quot; content=&quot;width=device-width, initial-scale=1&quot;&gt;
&lt;/head&gt;
&lt;body&gt;
    &lt;script src=&quot;https://api.qa.rectangle.health/cipherpay/api/v1/pay/rh-payment.js&quot;&gt;&lt;/script&gt;
&lt;/body&gt;
&lt;/html&gt;&#39;
        allow=&quot;payment&quot;
        width=&quot;400&quot;
        height=&quot;275&quot;
        sandbox=&quot;allow-scripts allow-forms allow-same-origin&quot;
        referrerpolicy=&quot;no-referrer&quot;
    &gt;&lt;/iframe&gt;
    &lt;section id=&quot;output-section&quot; aria-labelledby=&quot;output-heading&quot;&gt;
        &lt;div id=&quot;result&quot; aria-live=&quot;assertive&quot;&gt;&lt;/div&gt;
    &lt;/section&gt;
    &lt;script&gt;
        const CIPHERPAY_ORIGIN = null;
        window.addEventListener(&quot;message&quot;, (event) =&gt; {
            // Origin check — required in production to prevent spoofed messages.
            if (CIPHERPAY_ORIGIN &amp;&amp; event.origin !== CIPHERPAY_ORIGIN) return;

            const message = event.data;

            // We only handle the CipherPay standardized envelope.
            if (message.type !== &quot;PAYMENT_RESULT&quot;) return;

            const resultDisplay = document.getElementById(&quot;result&quot;);

            // Update the result banner with the appropriate style and text.
            if (resultDisplay) {
                resultDisplay.className = message.status; // applies &quot;success&quot;, &quot;failure&quot;, or &quot;error&quot; CSS class

                if (message.code === &quot;ENCRYPTED_DATA&quot; &amp;&amp; message.data?.encrypted) {
                    // Show a truncated preview so the customer sees something happened.
                    // In production you&#39;d likely redirect or show a confirmation instead.
                    resultDisplay.textContent = message.data.encrypted;
                } else {
                    resultDisplay.textContent = `${message.message} (${message.code})`;
                }
            }
            if (message.status === &quot;success&quot; &amp;&amp; message.code === &quot;ENCRYPTED_DATA&quot;) {
                console.log(&quot;Encrypted payload ready — send to your server:&quot;, message.data.encrypted);
            }
            if (message.status === &quot;success&quot; &amp;&amp; message.code === &quot;APPROVED&quot;) {
                const frame = document.getElementById(&quot;payment-frame&quot;);
                if (frame) frame.style.display = &quot;none&quot;;
            }
            if (message.status === &quot;failure&quot;) {
            }
            if (message.status === &quot;error&quot;) {
                console.error(&quot;CipherPay error:&quot;, message.code, message.message);
            }
        });
    &lt;/script&gt;
&lt;/body&gt;
&lt;/html&gt; </textarea><code class="language-html keep-markup drop-tokens">&lt;!doctype html&gt;
&lt;html lang=&quot;en&quot;&gt;
&lt;head&gt;
    &lt;meta charset=&quot;utf-8&quot; /&gt;
    &lt;title&gt;CNP-Encryption-Example&lt;/title&gt;
    &lt;meta name=&quot;viewport&quot; content=&quot;width=device-width, initial-scale=1&quot; /&gt;
&lt;/head&gt;
&lt;body&gt;
    &lt;h1&gt;CNP Encryption Example&lt;/h1&gt;
    &lt;iframe
        id=&quot;payment-frame&quot;
        srcdoc=&#39;&lt;!doctype html&gt;
&lt;html lang=&quot;en&quot;&gt;
&lt;head&gt;
    &lt;meta charset=&quot;utf-8&quot;&gt;
    &lt;meta name=&quot;viewport&quot; content=&quot;width=device-width, initial-scale=1&quot;&gt;
&lt;/head&gt;
&lt;body&gt;
    &lt;script src=&quot;https://api.qa.rectangle.health/cipherpay/api/v1/pay/rh-payment.js&quot;&gt;&lt;/script&gt;
&lt;/body&gt;
&lt;/html&gt;&#39;
        allow=&quot;payment&quot;
        width=&quot;400&quot;
        height=&quot;275&quot;
        sandbox=&quot;allow-scripts allow-forms allow-same-origin&quot;
        referrerpolicy=&quot;no-referrer&quot;
    &gt;&lt;/iframe&gt;
    &lt;section id=&quot;output-section&quot; aria-labelledby=&quot;output-heading&quot;&gt;
        &lt;div id=&quot;result&quot; aria-live=&quot;assertive&quot;&gt;&lt;/div&gt;
    &lt;/section&gt;
    &lt;script&gt;
        const CIPHERPAY_ORIGIN = null;
        window.addEventListener(&quot;message&quot;, (event) =&gt; {
            // Origin check — required in production to prevent spoofed messages.
            if (CIPHERPAY_ORIGIN &amp;&amp; event.origin !== CIPHERPAY_ORIGIN) return;

            const message = event.data;

            // We only handle the CipherPay standardized envelope.
            if (message.type !== &quot;PAYMENT_RESULT&quot;) return;

            const resultDisplay = document.getElementById(&quot;result&quot;);

            // Update the result banner with the appropriate style and text.
            if (resultDisplay) {
                resultDisplay.className = message.status; // applies &quot;success&quot;, &quot;failure&quot;, or &quot;error&quot; CSS class

                if (message.code === &quot;ENCRYPTED_DATA&quot; &amp;&amp; message.data?.encrypted) {
                    // Show a truncated preview so the customer sees something happened.
                    // In production you&#39;d likely redirect or show a confirmation instead.
                    resultDisplay.textContent = message.data.encrypted;
                } else {
                    resultDisplay.textContent = `${message.message} (${message.code})`;
                }
            }
            if (message.status === &quot;success&quot; &amp;&amp; message.code === &quot;ENCRYPTED_DATA&quot;) {
                console.log(&quot;Encrypted payload ready — send to your server:&quot;, message.data.encrypted);
            }
            if (message.status === &quot;success&quot; &amp;&amp; message.code === &quot;APPROVED&quot;) {
                const frame = document.getElementById(&quot;payment-frame&quot;);
                if (frame) frame.style.display = &quot;none&quot;;
            }
            if (message.status === &quot;failure&quot;) {
            }
            if (message.status === &quot;error&quot;) {
                console.error(&quot;CipherPay error:&quot;, message.code, message.message);
            }
        });
    &lt;/script&gt;
&lt;/body&gt;
&lt;/html&gt;</code></pre></div><p class="slate-p " ></p><h3 class="slate-h3 " >Response Example</h3><div class="code-block-wrapper"  style="width:100%;min-width:100%" ><div class="code-block-header">JSON</div><pre class="slate-CodeBlockElement slate-code_block"><textarea id="publishedPageCodeblock" style="display:none !important; visibility: hidden; opacity: 0; width: 1px; height: 1px;" type="hidden"> </textarea><code class="language-json keep-markup drop-tokens"><div class="slate-code_line"><div class="slate-code_line">{&quot;encrypted_card_data&quot;:{&quot;kid&quot;:&quot;d29775d4-fc38-425b-a38d-bf9a253a0a2c&quot;,&quot;ciphertext_b64&quot;:&quot;M6OBgZ6svvbGi3nrB3r5ftG2ogWfGNaNcb8DbsnzeFZ19fha3oq7tfwr0zsISK8cU7nrEKTDVOrXYuRk9+dGYXOfil3XOCVHXzIsrxVnfQ5v08Fjd5sJD42AEGre7WzFTOKlkcEz7iwRzyYxgZiUhnQxasnIQYHco5kxpeaur/aqsHyJqdF6+oVHMw+HZewBu/F6cIeaLqUFvVoajVg4JW5SN3txUY9/0bpAfHIVZ2QPSZmq6Hm0/dmVuFfis3374Jxjpi6QH8p44tBIhV36s3wADZa9iS+jdPj3C+8SFJZoGIw7uVkeGB3ROyf/fIUUUhxLd4hQc8MG0G0xTcyz2g==&quot;,&quot;nonce&quot;:&quot;NBOetRZbMh3LDfbMrNfCPwC1qJV5iUOT&quot;,&quot;issued_at&quot;:1776187237,&quot;expires_at&quot;:1776187297},&quot;amount&quot;:2000,&quot;currency&quot;:&quot;USD&quot;}</div></div></code></pre></div><p class="slate-p " ></p>

This script leverages client-side encryption of sensitive payment data before transmission to the server. It ensures that cardholder information is protected during transit by applying encryption algorithms within a secure browser-based environment. 

The embedded payment form supports custom styling via CSS, allowing integrators to align the user interface with their application's design. When applying custom styles, care should be taken to preserve usability, accessibility, and the integrity of required payment fields. 

Additionally, implementers should avoid modifying or interfering with the underlying payment logic and ensure that all interactions occur within the secure iframe context. 

M6OBgZ6svvbGi3nrB3r5ftG2ogWfGNaNcb8DbsnzeFZ19fha3oq7tfwr0zsISK8cU7nrEKTDVOrXYuRk9+dGYXOfil3XOCVHXzIsrxVnfQ5v08Fjd5sJD42AEGre7WzFTOKlkcEz7iwRzyYxgZiUhnQxasnIQYHco5kxpeaur/aqsHyJqdF6+oVHMw+HZewBu/F6cIeaLqUFvVoajVg4JW5SN3txUY9/0bpAfHIVZ2QPSZmq6Hm0/dmVuFfis3374Jxjpi6QH8p44tBIhV36s3wADZa9iS+jdPj3C+8SFJZoGIw7uVkeGB3ROyf/fIUUUhxLd4hQc8MG0G0xTcyz2g==

<p class="slate-p " >The following example demonstrates how to securely process payment transactions by submitting encrypted card data along with relevant transaction and account details. It supports capturing payment amounts and handling partial approvals for streamlined transaction processing and reconciliation. </p>

The following example demonstrates how to securely process payment transactions by submitting encrypted card data along with relevant transaction and account details. It supports capturing payment amounts and handling partial approvals for streamlined transaction processing and reconciliation. 

Securely encrypted card information complying with PCI standards for transmission

encrypted_card_data

Total transaction amount in the smallest currency unit, e.g., cents for USD

amount

Specifies the nature of the transaction, such as 'sale', 'authorization', or 'refund'

transaction_type

Code identifying the merchant’s account within the payment processing system

merchant_account_code

Invoice number or unique transaction reference provided by the merchant

inv_num

Indicates whether the transaction should accept a partial payment amount if full authorization is not possible

accept_partial_amount

Flag indicating whether the transaction is exempt from additional surcharge fees

non_surcharge

Identifier or name of the account holder initiating the transaction

account_holder

Specifies the media type of the resource or payload being sent in the request, e.g., application/json

Content-Type

Controls the desired type of connection for the HTTP request, such as 'keep-alive' or 'close'

Connection

API key used to authenticate the request against the payment gateway

x-api-key

Additional data or payload related to the transaction, containing custom or extended information.

data

A set of key-value pairs containing additional information or custom data related to the transaction.

metadata

<p class="slate-p " >The following example shows how to process a sale transaction using a previously generated <code class="slate-code">payment_token</code>. </p><p class="slate-p " >This request submits the transaction amount along with the associated <code class="slate-code">merchant_account_code</code> and uses the stored payment token to complete the payment without requiring card data. </p><div style="width:100%;
	min-width:100%;" class="callout-widget" data-type=warning ><div class="callout-icon"><svg width="18" height="16" viewBox="0 0 18 16" fill="none" xmlns="http://www.w3.org/2000/svg"><path d="M0.916637 15.5009C0.791637 15.5009 0.683998 15.4732 0.59372 15.4176C0.503443 15.362 0.430526 15.2857 0.37497 15.1884C0.319415 15.0912 0.288165 14.9905 0.28122 14.8864C0.274276 14.7822 0.305526 14.6745 0.37497 14.5634L8.4583 0.605103C8.52775 0.493991 8.60761 0.41413 8.69789 0.365519C8.78816 0.316908 8.88886 0.292603 8.99997 0.292603C9.11108 0.292603 9.21178 0.316908 9.30205 0.365519C9.39233 0.41413 9.47219 0.493991 9.54164 0.605103L17.625 14.5634C17.6944 14.6745 17.7257 14.7822 17.7187 14.8864C17.7118 14.9905 17.6805 15.0912 17.625 15.1884C17.5694 15.2857 17.4965 15.362 17.4062 15.4176C17.3159 15.4732 17.2083 15.5009 17.0833 15.5009H0.916637ZM1.99997 14.2509H16L8.99997 2.1676L1.99997 14.2509ZM9.0833 13.0634C9.26386 13.0634 9.41316 13.0044 9.53122 12.8864C9.64928 12.7683 9.7083 12.619 9.7083 12.4384C9.7083 12.2579 9.64928 12.1086 9.53122 11.9905C9.41316 11.8725 9.26386 11.8134 9.0833 11.8134C8.90275 11.8134 8.75344 11.8725 8.63539 11.9905C8.51733 12.1086 8.4583 12.2579 8.4583 12.4384C8.4583 12.619 8.51733 12.7683 8.63539 12.8864C8.75344 13.0044 8.90275 13.0634 9.0833 13.0634ZM9.0833 10.7509C9.26386 10.7509 9.41316 10.6919 9.53122 10.5739C9.64928 10.4558 9.7083 10.3065 9.7083 10.1259V6.70927C9.7083 6.52871 9.64928 6.37941 9.53122 6.26135C9.41316 6.1433 9.26386 6.08427 9.0833 6.08427C8.90275 6.08427 8.75344 6.1433 8.63539 6.26135C8.51733 6.37941 8.4583 6.52871 8.4583 6.70927V10.1259C8.4583 10.3065 8.51733 10.4558 8.63539 10.5739C8.75344 10.6919 8.90275 10.7509 9.0833 10.7509Z" fill="#F1C21B"></path></svg></div><div ><p class="slate-p " >If surcharge is enabled for the merchant account and the stored payment method is eligible (e.g., credit card), the transaction will include a surcharge. To explicitly prevent a surcharge from being applied, set <code class="slate-code">non_surcharge</code> to <code class="slate-code">true</code> in the request. </p></div></div><p class="slate-p " ></p>

The following example shows how to process a sale transaction using a previously generated 

This request submits the transaction amount along with the associated 

 and uses the stored payment token to complete the payment without requiring card data. 

payment_token

<p class="slate-p " >The following example shows how to initiate a void or refund request for completed transactions. Once the request is sent, the gateway checks the current settlement status of the transaction and proceeds accordingly - If the transaction is <em class="slate-italic">not </em>settled, it will process a void; if the transaction is settled, it will process a refund. </p>

The following example shows how to initiate a void or refund request for completed transactions. Once the request is sent, the gateway checks the current settlement status of the transaction and proceeds accordingly - If the transaction is 

settled, it will process a void; if the transaction is settled, it will process a refund. 

The unique identifier of the original transaction for which the refund is requested.

transaction_id

The amount to be refunded to the customer, specified in the request body.

refund_amount

The reason provided for initiating the refund, included in the request body.

refund_reason

The MIME type of the request body, typically set to application/json.

The HTTP header specifying the connection type, such as keep-alive or close.

The API key provided in the request header to authenticate and authorize the call.

An object containing detailed information about the refund transaction, including amounts and related identifiers.

A set of key-value pairs containing additional user-defined information associated with the refund.

Contains detailed information about the refund transaction including amounts, fees, and relevant identifiers.

Optional key-value pairs containing additional information provided by the client for tracking or auditing purposes.

<p class="slate-p " >The following example shows how to initiate a partial void or refund request for completed transactions. Once the request is sent, the gateway checks the current settlement status of the transaction and proceeds accordingly - If the transaction is <em class="slate-italic">not </em>settled, it will process a void; if the transaction is settled, it will process a refund. </p>

The following example shows how to initiate a partial void or refund request for completed transactions. Once the request is sent, the gateway checks the current settlement status of the transaction and proceeds accordingly - If the transaction is 

The unique identifier for the original transaction to be refunded, provided in the request body.

A descriptive reason for the refund, supplied in the request body.

Specifies the media type of the request body, typically application/json.

The value of the HTTP Connection header controlling whether the connection stays open or closes after the request.

The API key provided in the request header used to authenticate the client.

Additional data object containing extended information related to the refund.

Custom key-value pairs attached to the refund for internal tracking or integration purposes.

Partial void of $10 processed on $30 sale transaction. 

An object containing detailed information related to the refund transaction.

A key-value map for storing additional custom information related to the refund.

Partial refund of $10 processed on $20 sale transaction. 

<p class="slate-p " ></p><p class="slate-p " >This section outlines how to process transactions with surcharge applied using Rectangle Health Pay - Card Not Present (CNP). It covers how to submit surcharge-related details for sale transactions, as well as how to perform void, refund, and partial void/refund operations on surcharge transactions. </p><p class="slate-p " ></p><h3 class="slate-h3 " >Request Information</h3><p class="slate-p " >When processing surcharge transactions, the request must include all relevant transaction details. Surcharge behavior is controlled using the ‘<code class="slate-code">non_surcharge</code>’ field. When ‘<code class="slate-code">non_surcharge</code>’ is set to ‘<code class="slate-code">false</code>’, a surcharge will be applied. If this field is not provided, the default behavior is to apply the surcharge. </p><div class="published-table"><div class="table-container" style="padding-left: 0px;"><table class="slate-table" style="min-width:100%;"><div class="published-table-header" style="width:100%;min-width:100%;"><div style="width:97px;">Condition</div><div style="width:309px;">Data Element</div><div style="width:243px;">Data Type</div><div style="width:initial;">Description</div></div><colgroup ><col style="width:97px"><col style="width:309px"><col style="width:243px"><col style="width:initial"></colgroup><tbody class="slate-TableElement-tbody"><tr class="slate-tr " ><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >Required</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >non_surcharge</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >Boolean</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >If set to ‘false’ or not provided, a surcharge is applied. </p><p class="slate-p " >If set to ‘true’, no surcharge is applied. </p></td></div></tr></tbody></table></div></div><p class="slate-p " >The surcharge amount is automatically calculated based on the percentage configured for the account during onboarding and is added to the base transaction amount to form the total transaction amount. </p><h3 class="slate-h3 " ></h3><h3 class="slate-h3 " >Void/Refund on Surcharge Transactions</h3><p class="slate-p " >When performing a void or refund on surcharge transaction, the amount provided in the request must include the surcharge amount. </p><p class="slate-p " >For example, consider a transaction with a total amount of $20.60, where the base (net) amount is $20.00 and the surcharge (fee) amount is $0.60:</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">For a full void or refund, the amount specified in the request must be $20.60 (including the surcharge).</div></li><li class="slate-li " ><div style="position:relative">For a partial void or refund of $10.00 from the base amount, the total amount to be provided in the request must be $10.30 (including the prorated surcharge). </div><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">In this case:</div><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">The base (net) amount voided/refunded will be $10.00</div></li><li class="slate-li " ><div style="position:relative">The surcharge (fee) amount voided/refunded will be $0.30</div></li></ul></li></ul></li></ul><p class="slate-p " >The API automatically calculates and returns the breakdown of base (net) and surcharge (fee) amounts in the response, including the remaining balance after the transaction.</p><p class="slate-p " ></p><p class="slate-p " ></p>

This section outlines how to process transactions with surcharge applied using Rectangle Health Pay - Card Not Present (CNP). It covers how to submit surcharge-related details for sale transactions, as well as how to perform void, refund, and partial void/refund operations on surcharge transactions. 

When processing surcharge transactions, the request must include all relevant transaction details. Surcharge behavior is controlled using the ‘

’, a surcharge will be applied. If this field is not provided, the default behavior is to apply the surcharge. 

Condition

Data Element

Data Type

Description

The surcharge amount is automatically calculated based on the percentage configured for the account during onboarding and is added to the base transaction amount to form the total transaction amount. 

When performing a void or refund on surcharge transaction, the amount provided in the request must include the surcharge amount. 

For example, consider a transaction with a total amount of $20.60, where the base (net) amount is $20.00 and the surcharge (fee) amount is $0.60:

The API automatically calculates and returns the breakdown of base (net) and surcharge (fee) amounts in the response, including the remaining balance after the transaction.

<p class="slate-p " >The following example demonstrates how to securely process surcharge payment transactions by submitting encrypted card data along with relevant transaction, surcharge, and account details. It supports capturing payment amounts, including applicable surcharge amounts, and handling partial approvals for streamlined transaction processing and reconciliation. </p><p class="slate-p " >The surcharge will automatically be applied when the <code class="slate-code">nonSurcharge</code> field is set to false (if not provided, the default behavior is to apply the surcharge) based on the the percentage configured for the account during onboarding. </p>

The following example demonstrates how to securely process surcharge payment transactions by submitting encrypted card data along with relevant transaction, surcharge, and account details. It supports capturing payment amounts, including applicable surcharge amounts, and handling partial approvals for streamlined transaction processing and reconciliation. 

The surcharge will automatically be applied when the 

 field is set to false (if not provided, the default behavior is to apply the surcharge) based on the the percentage configured for the account during onboarding. 

The payment card information securely encrypted to ensure data protection during transmission.

The total monetary amount to be charged in the transaction, expressed in the smallest currency unit.

Specifies the type of transaction being performed, such as sale, refund, or authorization.

The unique code identifying the merchant's account within the payment system.

The invoice or reference number associated with the transaction.

Indicates whether the system should accept partial payment amounts if the full amount is unavailable.

Indicates whether the transaction amount excludes any additional surcharges.

The name of the cardholder or account owner initiating the payment.

Specifies the media type of the resource being sent in the request body, typically set to application/json.

Controls whether the network connection should remain open after the current transaction completes.

The API key used to authenticate the request with the payment gateway.

A container for additional data related to the transaction, such as nested objects or custom attributes.

A set of key-value pairs containing additional customizable information associated with the transaction.

<p class="slate-p " >The following example shows how to initiate a void or refund request for completed surcharge transactions. Once the request is sent, the gateway checks the current settlement status of the surcharge transaction and proceeds accordingly - If the transaction is not settled, it will process a void; if the transaction is settled, it will process a refund. </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 " >As this request applies to a surcharged transaction, the amount provided must include the surcharge amount. </p></div></div><p class="slate-p " ></p>

The following example shows how to initiate a void or refund request for completed surcharge transactions. Once the request is sent, the gateway checks the current settlement status of the surcharge transaction and proceeds accordingly - If the transaction is not settled, it will process a void; if the transaction is settled, it will process a refund. 

The unique identifier of the original transaction to be refunded.

The amount to be refunded to the customer, specified in the smallest currency unit.

The explanation provided for initiating the refund, describing the cause or context.

HTTP header specifying the media type of the request body, typically application/json.

HTTP header that controls whether the network connection stays open after the current transaction completes.

HTTP header containing the API key used to authenticate the refund request.

Additional data or payload returned by the payment processor related to the transaction.

A key-value store of additional information or custom data related to the refund transaction.

Void processed on $30.90 surcharged transaction (Net Amount - $30.00, and Surcharge/Fee Amount - $0.90). 

An object containing detailed information related to the refund transaction including amounts, status, and identifiers.

A set of key-value pairs for storing additional information related to the refund that is not part of the core response.

Refund processed on $10.30 surcharged transaction (Net Amount - $10.00, and Surcharge/Fee Amount - $0.30). 

<p class="slate-p " >The following example shows how to initiate a partial void or refund request for completed surcharge transactions. Once the request is sent, the gateway checks the current settlement status of the surcharge transaction and proceeds accordingly - If the transaction is not settled, it will process a void; if the transaction is settled, it will process a refund. </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 " >As this request applies to a surcharged transaction, the amount provided must include the surcharge amount. </p></div></div><p class="slate-p " ></p>

The following example shows how to initiate a partial void or refund request for completed surcharge transactions. Once the request is sent, the gateway checks the current settlement status of the surcharge transaction and proceeds accordingly - If the transaction is not settled, it will process a void; if the transaction is settled, it will process a refund. 

The unique identifier of the original transaction to which the refund applies.

The amount to be refunded to the customer, specified in the smallest unit of the currency.

A descriptive reason provided for initiating the refund, explaining the cause or context of the refund request.

HTTP header specifying the media type of the request body, typically 'application/json' for this endpoint.

HTTP header indicating the desired connection management options, such as 'keep-alive' or 'close'.

The API key provided in the request header to authenticate and authorize access to the refund endpoint.

Additional data related to the refund or void request, which may include processor-specific information.

A key-value store for storing additional, customizable information related to the refund or void request.

Partial void of $10.00 (including surcharge amount) processed on $30.90 surcharged transaction (Net amount - $30.00, Surcharge/fee amount - 0.90). The voided amount consists of $9.71 base and $0.29 surcharge. The remaining transaction amount is $20.90, including $20.29 base and $0.61 surcharge.



A key-value map for storing custom data associated with the refund, allowing for flexible tracking.

Partial refund of $5.15 (including surcharge amount) processed on $10.30 surcharged transaction (Net amount - $10.00, Surcharge/fee amount - 0.30). The refunded amount consists of $5.00 base and $0.15 surcharge. The remaining transaction amount is $5.15, including $5.00 base and $0.15 surcharge.

<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 " >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>

Sections