> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.redpincompany.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.redpincompany.com/_mcp/server.

# Changelog

Stay up-to-date with the latest improvements, new features, and changes to the Redpin Platform API.

> **Note**
>
> We regularly update our API to provide better functionality and security. All changes are backwards compatible unless explicitly noted.

## What's in a changelog entry?

Each changelog entry includes:

* **Summary**: Overview of the release
* **New Features**: Fresh functionality added to the API
* **Bug Fixes**: Issues resolved in this version
* **Breaking Changes**: Any changes that might affect existing integrations

## October 8, 2026

## Summary

**Breaking change in [`@redpincompany/hosted-payment-sdk` 2.0.0](https://www.npmjs.com/package/@redpincompany/hosted-payment-sdk/v/2.0.0)**: The hosted thank-you page no longer posts `VIEW_ALL_PAYMENTS`. It posts `REDPIN_PAYMENT_TRACKING_EXITED`. The SDK maps that message to `onPaymentFlowExited` (`() => void`). `onViewAllPayments` is not called.

## Documentation Updates

### Page updates

* [Quickstart setup](/api-guide/partners/quickstart-setup) — React Native SDK example and callback list now use `onPaymentFlowExited`. The callback fires when the user exits payment tracking from the thank-you page. Use it to leave the hosted flow.

## September 30, 2026

## Summary

[List payment sessions](/api-reference/customers/hosted-experience/sessions/list-payment-sessions): `GET /v1/customers/{customer_id}/sessions` now includes [`payment_method`](/api-reference/customers/hosted-experience/sessions/list-payment-sessions#response.body.sessions.payment_method) once the buyer has selected a payment method. The path, query parameters, and pagination envelope are unchanged.

## API Changes

### [List payment sessions](/api-reference/customers/hosted-experience/sessions/list-payment-sessions)

* **Endpoint**: `GET /v1/customers/{customer_id}/sessions`
* **New optional field**: [`payment_method`](/api-reference/customers/hosted-experience/sessions/list-payment-sessions#response.body.sessions.payment_method) on each session item
* **Values**: `PAY_BY_BANK`, `MANUAL_TRANSFER`
* **Present** once the session has reached `USER_SETUP_TRANSFER`

## September 29, 2026

## Summary

**Payment scheme note in bank transfer instructions**: The [Get Bank Transfer Instructions](/api-reference/customers/api-integration/payments/get-payment-bank-transfer-instructions) response now includes an optional `payment_scheme_note` field.

## Enhancements

### [Get Bank Transfer Instructions](/api-reference/customers/api-integration/payments/get-payment-bank-transfer-instructions)

* **Endpoint**: `GET /v3/customers/{customer_id}/payments/{payment_id}/bank-transfer-instructions`
* **New field**: `payment_scheme_note` (string, optional)
* **Purpose**: Guidance on which payment schemes the beneficiary account accepts
* **Behaviour**: Varies by the [`from_country`](/api-reference/customers/api-integration/payments/get-payment-bank-transfer-instructions#request.query.from_country) query parameter, and may be absent. When absent, the field is omitted from the response rather than returned as `null`

This is distinct from `payment_reference.disclaimer`, which explains why the payment reference must be included for the payment to be processed and reconciled.

All other fields in the response are unchanged. This is a backwards-compatible addition.

**Example response:**

```json
{
  "payment_method": "international_transfer",
  "amount": {
    "currency": "GBP",
    "value": 1000.45
  },
  "account_details": {
    "name": "Currencies Direct Inc",
    "address": "4705 South Apopka-Vineland Road, Suite 114, Orlando, Florida, 32819 USA"
  },
  "bank_details": {
    "name": "Barclays",
    "address": "1 Churchill Place, Canary Wharf, London, United Kingdom",
    "routing_codes": [
      {
        "type": "IBAN",
        "value": "GB06BARC20199075274900",
        "label": "IBAN"
      },
      {
        "type": "SWIFTBIC",
        "value": "BARCGB22",
        "label": "SWIFTBIC"
      }
    ]
  },
  "payment_reference": {
    "value": "ABCD123456",
    "label": "Payment reference",
    "disclaimer": "Always include this payment reference – it tells us the money has come from you."
  },
  "payment_scheme_note": "Please note: This account only accepts FPS, BACS and CHAPS payments. FPS payments are available for amounts up to £1 million."
}
```

## Integration Notes

Check for the presence of the key before rendering it. Clients that ignore unknown fields require no change.

## August 19, 2026

## Summary

**Hosted analytics consent**: Documented the embedded hosted-session contract for forwarding analytics consent from the host application. Hosts send a `SET_ANALYTICS_CONSENT` message so product analytics and session diagnostics stay off until analytics consent is granted. The hosted page listens for that message and does not emit a consent-ready event.

## Documentation Updates

### Page updates

* [Integration guidelines](/api-guide/partners/integration-guidelines) — Added Step 6: Analytics consent integration (embedded hosts), with React iframe and React Native WebView snippets. Subsequent hosted workflow steps are renumbered (webhooks to Step 7, session expiration to Step 8). Compliance requirements now distinguish KYC data-sharing consent from analytics consent.
* [Quickstart setup](/api-guide/partners/quickstart-setup) — Links to the analytics consent section alongside theme customization. React Native SDK `PaymentSDKConfigType` now includes optional `analyticsConsent` (default `false`).

## July 15, 2026

## Summary

**Payment status and webhook payload optimization**: Removed all references to the `REFUNDED` status across our API schemas, webhook event flows, and documentation to align with current API capabilities. Additionally, simplified webhook payloads for `CANCELLED` and `BOUNCED_BACK` events by removing metadata parameters (`reason_description` and `bounce_reason`), streamlining downstream event consumption.

## API Changes

### Schema updates

* **Payment status enums**: Removed the `REFUNDED` state from payment and recipient status tracking schemas.
* **Webhook event payloads**:
  * Removed `reason_description` from the `CANCELLED` webhook event schema.
  * Removed `bounce_reason` from the `BOUNCED_BACK` webhook event schema.
  * Removed refund-related attributes (`refund_amount`, `refund_reason`) from webhook schemas.

## Documentation Updates

### Page updates

* [Payment reconciliation guide](/api-guide/webhooks/reconciliation) — Updated status diagrams, flowchart paths, and JSON payload examples to exclude `REFUNDED` state references and associated cancellation/bounce reasons.
* [Webhook simulator](/api-guide/partners/webhook-simulator) — Streamlined the "Bounced Back" simulation scenario documentation to reflect the removed bounce metadata.
* [Integration guidelines](/api-guide/partners/integration-guidelines) — Removed references to refund failure notifications.

## July 1, 2026

## Summary

**Webhook event simulator**: Expanded the sandbox webhook event simulator to support new realistic failure and edge-case status flows: `"Cancel Payment — Funding Failure"`, `"Cancel Payment — Payout Failure"`, and `"Bounced Back"`. These updates allow developers to test end-to-end integration and error handling paths in a scripted environment.

## Documentation Updates

### Page updates

* [Test webhooks with the simulator](/api-guide/partners/webhook-simulator) — Documented the new test scenarios with step-by-step event sequence guides:
  * **Cancel Payment — Funding Failure**: Simulates a payment cancelled before the FX stage.
  * **Cancel Payment — Payout Failure**: Simulates a downstream banking rejection/failure during the payout phase.
  * **Bounced Back**: Simulates a payout rejected and returned by the recipient bank after successful debiting.

## May 13, 2026

## Summary

**Webhook event simulator**: Added a partner-facing guide for the sandbox webhook event simulator at [simulator.sandbox.redpincompany.com](https://simulator.sandbox.redpincompany.com), which lets you exercise your webhook handler against a scripted sequence of payment lifecycle events for a given session.

## Documentation Updates

### New page

* [Test webhooks with the simulator](/api-guide/partners/webhook-simulator) — how to load a sandbox session, pick a scripted action (Successful Payment Completion, Cancel Payment), publish the event sequence, and inspect the deliveries the simulator sent to your registered callback URL.

### Cross-links

* [Webhooks overview](/api-guide/webhooks) now points to the simulator for handler verification.
* [Integration guidelines](/api-guide/partners/integration-guidelines) references the simulator within the hosted-flow webhook subscription step.
* [Getting started](/api-guide/getting-started) includes the simulator as a next step alongside webhook configuration.

## March 5, 2026

## Summary

🚀 **Hosted Sessions Listing API**: Added a new read endpoint to list hosted payment sessions for a customer, including idempotency lookup by `client_reference_id`.

## New Features

### Hosted Experience Sessions

* **New endpoint**: `GET /v1/customers/{customer_id}/sessions`
* **Primary idempotent lookup flow**: `GET /v1/customers/{customer_id}/sessions?client_reference_id={ref}`
* **Supports pagination** using `page` and `limit`
* **Response includes** `sessions` and `meta` with pagination fields (`page`, `limit`, `total_records`, `total_pages`)
* Session records include fields such as:
  * `session_id`
  * `client_reference_id`
  * `client_customer_ref`
  * `customer_id`
  * `created_at`
  * `session_expires_at`
  * `latest_status`
  * `has_payment` and `payment_id` (when available)

## Documentation Updates

* Updated the payment reconciliation guide to include a retry recovery pattern:
  * If session creation response is lost or a retry occurs, first query sessions by `client_reference_id` for the same `customer_id` to fetch the existing session and avoid duplicate creation.

## February 18, 2026

## Summary

🚀 **Hosted Payment Sessions Multi-Currency & Non-IBAN Support**: Enhanced Hosted Payment Sessions to support multiple currencies and non-IBAN regions by enabling developers to reference pre-created recipients instead of embedding recipient details in session requests.

> **Note**
>
> Hosted Payment Sessions now support all currencies and bank detail formats, enabling international expansion beyond UAE/IBAN regions. Developers can now create recipients once and reuse them across multiple payment sessions.

## New Features

### Recipient ID-Based Payment Sessions

#### [Create Payment Session](/api-reference/customers/hosted-experience/sessions/create-payment-session)

* **What's New**: Updated `recipient_details` structure to use `recipient_id` instead of embedded recipient objects
* **Purpose**: Enable support for multiple currencies and non-IBAN bank detail formats
* **Key Changes**:
  * `recipient_details` now requires `recipient_id` instead of full recipient object
  * Simplified structure: `amount`, `payment_reference`, `purpose_of_transaction`, and `recipient_id`
  * Recipients must be created separately using the [Add a New Recipient](/api-reference/customers/api-integration/recipients/add-a-new-recipient) API before creating a session

### Enhanced Hosted Integration Workflow

#### [Integration Guidelines](/api-guide/partners/integration-guidelines)

* **What's New**: Updated Hosted integration workflow to include recipient creation step
* **Workflow Changes**:
  * **Step 2: Recipient creation** - New step added to create recipients before session creation
  * **Step 3: Session creation** - Updated to reference recipients by ID
  * Updated all examples to use the new simplified `recipient_details` structure

## Breaking Changes

⚠️ **Important**: This is a breaking change for existing integrations using Hosted Payment Sessions.

The `recipient_details` structure in payment session requests has changed. Instead of embedding full recipient objects (name, address, bank details) directly in the session request, you must now reference pre-created recipients using `recipient_id`. This change enables support for multiple currencies and non-IBAN bank detail formats.

### Migration Steps

1. **Create Recipients First**: Use the [Add a New Recipient](/api-reference/customers/api-integration/recipients/add-a-new-recipient) API to create recipients with their bank details
2. **Store Recipient IDs**: Save the `recipient_id` returned from the recipient creation response
3. **Update Session Creation**: Modify your payment session creation requests to use `recipient_id` instead of embedded recipient objects

### Structure Comparison

**Previous Structure (No Longer Supported):**

```json
"recipient_details": [
  {
    "amount": {
      "currency": "AED",
      "value": 3000.25
    },
    "recipient": {
      "name": "John Doe",
      "type": "Individual",
      "payment_reference": "RentAug",
      "address": { ... },
      "recipient_bank_details": { ... },
      "purpose_of_transaction": "PROPERTY_PURCHASE"
    }
  }
]
```

**New Structure (Required):**

```json
"recipient_details": [
  {
    "amount": {
      "currency": "AED",
      "value": 3000.25
    },
    "payment_reference": "RentAug",
    "purpose_of_transaction": "PROPERTY_PURCHASE",
    "recipient_id": "123456"
  }
]
```

## API Reference Updates

* [Create Payment Session](/api-reference/customers/hosted-experience/sessions/create-payment-session) - Updated request structure
* [Add a New Recipient](/api-reference/customers/api-integration/recipients/add-a-new-recipient) - Required before creating sessions
* [Integration Guidelines](/api-guide/partners/integration-guidelines) - Updated workflow documentation

## January 7, 2026

## Summary

🚀 **Currency Expansion & Recipient Management Enhancements**: Added support for payout currencies and enhanced recipient management with currency-specific fields for better compliance and data management.

> **Note**
>
> Recipient APIs now support currency-specific additional details, enabling compliance with local regulatory requirements for different payout currencies.

## New Features

### Payout Currencies Support

#### [Get Currencies](/api-reference/customers/api-integration/references/get-currencies)

* **What's New**: Added `payout_currencies` array to the currencies reference endpoint
* **Purpose**: Returns the list of currencies that can be used for payouts in your organisation
* **Benefits**:
  * Enables clients to programmatically determine available payout currencies
  * Supports dynamic currency selection in payment workflows
  * Provides clear visibility into supported payout options

### Enhanced Recipient Management

#### [Add a New Recipient](/api-reference/customers/api-integration/recipients/add-a-new-recipient) & [Update a Recipient's Account](/api-reference/customers/api-integration/recipients/update-a-recipients-account)

* **What's New**: Added `additional_details` object to both recipient creation and update payloads
* **Purpose**: Support currency-specific fields required for different payout currencies
* **Key Features**:
  * Flexible map structure for currency-specific information
  * Example structure:
    ```json
    "additional_details": {
      "tax_id": "AH12345678"
    }
    ```
  * **Supported Currencies and Fields**:
    * **BRL (Brazilian Real)**: Tax ID must be provided in the `tax_id` field
    * **KRW (South Korean Won)**: Business Registration number must be provided in the `tax_id` field
    * **PKR (Pakistani Rupee)**: Identification number must be provided in the `tax_id` field
    * **ISK (Icelandic Króna)**: Supported currency for currency-specific recipient payloads
  * Enables compliance with local regulatory requirements
  * Allows modification of tax identification numbers or registration details when updating recipients

#### [Get Recipients](/api-reference/customers/api-integration/recipients/get-recipients) & [Get Recipient Details](/api-reference/customers/api-integration/recipients/get-recipient)

* **What's New**: Response now includes `additional_details` object
* **Purpose**: Retrieve tax identification numbers or registration numbers for recipients when available
* **Key Features**:
  * Returns currency-specific recipient information
  * Provides complete recipient profile including compliance data
  * Supports audit and compliance workflows

## Breaking Changes

* None. All changes are additive and backward compatible.

## December 30, 2025

## Summary

🚀 **Create Payment API Enhancement**: The Create Payment API now supports optional FX conversion, allowing you to create same-currency payments without requiring a quote. FX conversion is optional - provide a `quote_id` only when currency conversion is needed.

> **Note**
>
> The Create Payment API now provides flexible payment creation workflows. For same-currency payments, simply omit the `quote_id`. For FX conversions, provide an active `quote_id` from a valid quote.

## API Updates

### [Create Payment](/api-reference/customers/api-integration/payments/create-payment)

* **Endpoint**: `POST /v3/customers/:customer_id/payments`
* **What's New**: FX conversion is now optional in the payment creation workflow
* **Key Changes**:
  * **FX Conversion (Optional)**: If you need to convert currency, provide a `quote_id` from an active quote
    * The quote must be active and not expired
    * Quote validation ensures accurate FX rates and conversion amounts
  * **Same Currency Payment**: If no currency conversion is needed (same currency payment), do not send `quote_id`
    * Enables direct same-currency payments without requiring a quote
    * Streamlines payment creation for domestic or same-currency transfers

**Usage Guidelines**:

* **For FX Conversion Payments**: Include `quote_id` in the request payload. The quote must be active and not expired.
* **For Same Currency Payments**: Omit `quote_id` from the request payload. The payment will be processed without currency conversion.

## Webhook Updates

### [Payment Status Updated Event](/api-reference/webhooks/webhook-payment-status-updated)

Updated payment status descriptions to clarify when each status applies:

| Status           | Description                                                                                                | Applies To                  |
| ---------------- | ---------------------------------------------------------------------------------------------------------- | --------------------------- |
| `PROCESSING`     | Payment is being processed. Immediately after the response from Payment v3 call for same-currency payments | Same currency payments only |
| `AWAITING_FUNDS` | Payment created, waiting for funds to be received                                                          | FX conversion payments      |
| `RECEIVED_FUNDS` | Funds have been received and credited to customer's Redpin wallet                                          | FX conversion payments      |

**Status Flow Differences**:

* **Same Currency Payments**: Start with `PROCESSING` status immediately after payment creation
* **FX Conversion Payments**: Start with `AWAITING_FUNDS` status, then transition to `RECEIVED_FUNDS` when funds are received

## Breaking Changes

* None. The `quote_id` field remains optional, maintaining backward compatibility with existing integrations.

## December 22, 2025

## Summary

📋 **Legacy Payment APIs Documentation**: Documented legacy v2 Payment API endpoints and provided migration guidance to help existing integrations transition to the improved v3 Payments API.

> **Note**
>
> All Legacy API endpoints have been superseded by newer versions that offer improved functionality and consistency. We strongly recommend migrating to the latest versions for better performance, enhanced tracking, and improved error handling.

## Legacy Payment APIs

### [Legacy APIs](/api-reference/customers/api-integration/legacy-ap-is)

* **What's New**: Documented legacy v2 Payment API endpoints
* **Purpose**: Provide migration guidance for existing integrations
* **Status**: These endpoints remain functional but are no longer actively developed. New features and improvements are only available in the v3 Payments API.

### Migration Guide

The following legacy endpoints have been superseded by v3 alternatives:

| Legacy endpoint                                         | Recommended alternative                                                                           |
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| `POST /v2/customers/{customer_id}/payments`             | [Create Payment (v3)](/api-reference/customers/api-integration/payments/create-payment)           |
| `GET /v1/customers/{customer_id}/payments`              | [List Payments (v3)](/api-reference/customers/api-integration/payments/list-payments)             |
| `GET /v1/customers/{customer_id}/payments/{payment_id}` | [Get Payment Details (v3)](/api-reference/customers/api-integration/payments/get-payment-details) |

### Benefits of Migrating to v3

The v3 Payments API provides several improvements over the legacy endpoints:

* **Unified workflow**: Combined FX conversion and payment creation in a single request
* **Enhanced tracking**: More detailed payment status information
* **Bank transfer instructions**: Dedicated endpoint for retrieving funding instructions
* **Improved error handling**: More detailed and actionable error responses
* **Same-currency support**: Handles both FX conversion and same-currency payments

### Breaking Changes

* None. Legacy endpoints remain functional. However, we strongly recommend migrating to v3 for improved functionality and consistency.

## October 15, 2025

## Summary

**Regulatory Compliance Updates**: Added comprehensive guides for Confirmation of Payee (CoP) and Verification of Payee (VoP), covering all error codes, step-by-step resolution workflows, and updated API support for regulatory verification retries.

## New Documentation

### Regulatory Compliance Guides

* **[Confirmation of Payee (CoP) Guide](/api-guide/regulatory-guides/cop-guide)**: Complete guide covering CoP verification errors and their corresponding resolution workflows for UK payments.

* **[Verification of Payee (VoP) Guide](/api-guide/regulatory-guides/vop-guide)**: Complete guide covering VoP verification errors and their corresponding resolution workflows for EUR(SEPA) payments.

## API Updates

### New Request Fields

* **`confirm_recipient`** (optional): Added under `recipient_details` in the [Create Payment API](/api-reference/customers/api-integration/payments/create-payment) to allow retrying a payment for recipients that failed CoP or VoP checks
  * Enables retrying payments after **CoP/VoP** verification failures
  * Includes `customer_action`, `request_identifier`, and `event_id` fields

## August 14, 2025

## Summary

**Third Party Customer Status Webhook**: Added webhook notifications for third party customer status updates.

## New Features

### Third Party Customer Status Webhook

* **What’s New**: Platforms can now receive real-time webhook notifications when the status of a third party customer changes (e.g., from `PENDING` to `APPROVED` or `REJECTED`).
* **How it Works**: When a third party customer's compliance status is updated, Redpin will send a webhook event to your configured endpoint with the latest status and customer reference.
* **Benefits**:
  * Enables instant updates to your platform when customer onboarding or compliance review is completed.
  * Reduces the need for polling the API for status changes.
* **Event Payload Example**:
  ```json
  {
    "event_id": "3",
    "event_timestamp": "2025-01-01T00:00:00Z",
    "customer_id": "0201001008132685",
    "client_customer_ref": "CUST_001",
    "status": "APPROVED"
  }
  ```
* **Documentation**: See [Third Party Customer Webhook Events](/api-reference/webhooks/webhook-third-party-customer-status-updated) for integration details and setup instructions.

## Bug Fixes

* N/A

## Breaking Changes

* None. This is a non-breaking, additive change.

## July 17, 2025

## Summary

📖 **New Integration Guides**: Added comprehensive documentation to help developers integrate with Redpin's APIs more effectively.

## New Documentation

### Integration Guides

* **[Getting Started](/api-guide/getting-started)**: Overview of Redpin's APIs and core payment workflows
* **[Making Your First Payment](/api-guide/getting-started/making-your-first-payment)**: Step-by-step tutorial for processing test payments
* **[Error Handling](/api-guide/getting-started/error-handling)**: Best practices for handling API errors and implementing retry logic
* **[Integration Guidelines](/api-guide/partners/integration-guidelines)**: Complete guide for partners choosing integration approaches
* **[Sandbox to Production](/api-guide/getting-started/sandbox-to-production)**: Requirements and checklist for production deployment

## July 15, 2025

## Summary

🚀 **New Third Party Customer APIs**: Added APIs for property developers and real estate platforms to manage end-user customer profiles.

> **Note**
>
> These APIs enable property developers, real estate platforms, and fractional investment platforms to onboard and manage their customers for international property payments while maintaining compliance requirements.
> 🚀 **New API Endpoint Released**: We’ve added the **Create Payment Session** API to the Hosted B2B API suite, enabling platforms to initiate secure, temporary payment sessions for hosted integration use cases.

> **Note**
>
> The **Create Payment Session API** is now available for integration. It enables you to generate a hosted payment session and receive a secure session URL for seamless cross-border payments. The API supports multiple recipients and integrates smoothly with your system via robust callback/webhook support.

## New Features

### Create Third-Party Customer

* **Api-Reference**: [Create Third Party Customer](/api-reference/customers/api-integration/third-parties/create-third-party-customer)
* **Endpoint**: `POST /api/v1/customers/{customer_id}/third-parties`
* **Purpose**: Onboard end users (buyers/investors) for property transactions without creating direct Redpin customer relationships

### Get Third-Party Customer

* **Api-Reference**: [Get Third Party Customer](/api-reference/customers/api-integration/third-parties/get-third-party-customer)
* **Endpoint**: `GET /api/v1/customers/{customer_id}/third-parties/{client_customer_reference}`
* **Purpose**: Retrieve customer profiles and compliance status for ongoing transaction management

### Update Third-Party Customer

* **Api-Reference**: [Update Third Party Customer](/api-reference/customers/api-integration/third-parties/update-third-party-customer)
* **Endpoint**: `PUT /api/v1/customers/{customer_id}/third-parties/{client_customer_reference}`
* **Purpose**: Update customer information and trigger re-verification when needed

### [Create Payment Session API](/api-reference/customers/hosted-experience/sessions/create-payment-session)

* **Endpoint**: `POST /api/v1/customers/:customer_id/sessions`
* **Purpose**: Start a hosted payment session for cross-border payments.
* **Highlights**:
  * Generates a secure, time-limited session URL for embedding in your app or website
  * Supports multi-recipient payments with detailed recipient and bank account data
  * Configurable allowed origins and callback URLs for real-time status updates
  * Secured with OAuth 2.0 authentication
  * Sessions automatically expire at the defined timestamp; a new session must be created if the previous one expires before completion

## July 14, 2025

## Summary

🚀 **New Recipient Management APIs**: The B2B API suite now includes new endpoints to add, update, and retrieve recipient details, making it easier to manage business payments.

> **Note**
>
> Securely manage recipient records with comprehensive APIs for adding, updating, and retrieving recipient details using OAuth 2.0 authentication.

## Recipient API Endpoints

### [Add Recipient](/api-reference/customers/api-integration/recipients/add-a-new-recipient)

* **Endpoint**: `POST /v2/customers/:customer_id/recipients`.
* **Purpose**: Register a new recipient with personal and bank account details for future payments.
* **Highlights**:
  * Supports both individual and corporate recipients.
  * Collects comprehensive recipient information (name, contact, address, country).
  * Flexible bank account input: IBAN, account number + SWIFT, routing codes, and more.

### [Update Recipient](/api-reference/customers/api-integration/recipients/update-a-recipients-account)

* **Endpoint**: `PUT /v2/customers/:customer_id/recipients/:recipient_id`.
* **Purpose**: Update an existing recipient’s details, such as contact information or bank account data.
* **Highlights**:
  * Modify recipient personal, contact, or bank details.
  * Maintain up-to-date records for compliance and payment accuracy.

### [Get All Recipients](/api-reference/customers/api-integration/recipients/get-recipients)

* **Endpoint**: `GET /v2/customers/:customer_id/recipients`.
* **Purpose**: Retrieve a list of all recipients registered for a specific customer.
* **Highlights**:
  * List all recipients for a customer, including their details and status.
  * Supports pagination for large recipient lists.
  * Useful for displaying recipient options in your application.

## July 11, 2025

## Summary

🔔 **New Webhook Events**: Added webhook APIs for real-time status updates on customers, virtual accounts, and payments.

> **Note**
>
> You can now subscribe to webhook events for customer status, virtual account status, and payment status updates. Your application will receive structured JSON payloads at your designated endpoint whenever these statuses change.

## New Features

### [Customer Status Updated Webhook](/api-reference/webhooks/webhook-customer-status-updated)

* **Event**: `customer_status_updated`
* **Purpose**: Receive notifications when a customer's status changes (e.g., active/inactive).
* **Payload**: Includes customer details, status, and required documents.

### [Virtual Account Status Updated Webhook](/api-reference/webhooks/webhook-virtual-account-status-updated)

* **Event**: `virtual_account_status_updated`
* **Purpose**: Get notified when a virtual account becomes active or closed.
* **Payload**: Includes virtual account details, status, and bank information.

### [Payment Status Updated Webhook](/api-reference/webhooks/webhook-payment-status-updated)

* **Event**: `payment_status_updated`
* **Purpose**: Track the full payment journey with granular status updates (e.g., awaiting funds, FX completed, payout credited, etc.).
* **Payload**: Status-specific data for each payment event, including amounts, currencies, recipients, and more.

## July 10, 2025

## Summary

🚀 **New API Endpoints**: Added the "Create Quote" and "Get Recipient Details" APIs to the B2B API suite, enabling businesses to request currency quotations and retrieve recipient information for seamless payment processing.

> **Note**
>
> The Create Quote and Get Recipient Details APIs are now available for integration. These endpoints provide comprehensive quote creation and recipient management capabilities for seamless international payment processing.

## New Features

### [Create Quote API](/api-reference/customers/api-integration/quotes/create-quote)

* **Endpoint**: `POST /v1/customers/:customer_id/quotes`
* **Purpose**: Request fixed price quotations for currency exchange
* **Key Features**:
  * Supports both BUY and SELL fixed side scenarios
  * Validates currency codes and amount precision
  * Returns comprehensive quote details with expiry timestamps
  * Provides real-time exchange rates and converted amounts
  * Includes detailed validation for supported currency combinations

### [Get Recipient Details API](/api-reference/customers/api-integration/payments/get-recipient)

* **Endpoint**: `GET /v2/customers/:customer_id/recipients/:recipient_id`
* **Purpose**: Retrieve detailed recipient information for payment processing
* **Key Features**:
  * Returns complete recipient profile including bank details
  * Supports both Individual and Corporate recipient types
  * Includes address validation and formatting standards
  * Provides comprehensive bank account information (IBAN, SWIFT, routing codes)
  * Returns recipient status and validation information

## Technical Features

* **Authentication**: OAuth 2.0 Bearer token authentication required
* **Validation**: Comprehensive input validation with detailed error messages
* **Documentation**: Complete API documentation with practical examples
* **Error Handling**: Detailed error responses with field-level information
* **Examples**: Realistic request/response examples for seamless integration

## July 9, 2025

## Summary

🚀 **New API Endpoints**: Added the "Create Payment" and "Get Bank Transfer Instructions" APIs to the B2B API suite, enabling businesses to create FX conversions and retrieve detailed bank transfer instructions for pending international payments.

> **Note**
>
> The Create Payment and Get Bank Transfer Instructions APIs are now available for integration. These endpoints provide comprehensive payment creation and bank transfer details for seamless international payment processing.

## New Features

### [Create Payment API](/api-reference/customers/api-integration/payments/create-payment)

* **Endpoint**: `POST /v3/customers/:customer_id/payments`
* **Purpose**: Create FX conversion and payment with recipient details
* **Key Features**:
  * Supports single and multiple recipient payments
  * Validates payment amounts against quote details
  * Generates unique payment IDs for tracking
  * Returns comprehensive payment status and recipient information

### [Get Bank Transfer Instructions API](/api-reference/customers/api-integration/payments/get-payment-bank-transfer-instructions)

* **Endpoint**: `GET /v3/customers/:customer_id/payments/:payment_id/bank-transfer-instructions`
* **Purpose**: Retrieve detailed bank transfer instructions for pending payments
* **Key Features**:
  * Returns complete bank account details (account number, routing number, SWIFT/BIC codes)
  * Provides payment-specific reference information
  * Includes transfer amount and currency details
  * Returns clear payment instructions and notes

_Showing the 20 most recent of 21 entries. Append `/llms.txt` to the changelog URL for the complete index._