Changelog

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

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

May 13, 2026

Summary

Webhook event simulator: Added a partner-facing guide for the sandbox webhook event simulator at 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 — 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 now points to the simulator for handler verification.
Integration guidelines references the simulator within the hosted-flow webhook subscription step.
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.

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

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 before creating a session

Enhanced Hosted Integration Workflow

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

Create Recipients First: Use the Add a New Recipient API to create recipients with their bank details
Store Recipient IDs: Save the recipient_id returned from the recipient creation response
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):

1 "recipient_details": [
2   {
3     "amount": {
4       "currency": "AED",
5       "value": 3000.25
6     },
7     "recipient": {
8       "name": "John Doe",
9       "type": "Individual",
10       "payment_reference": "RentAug",
11       "address": { ... },
12       "recipient_bank_details": { ... },
13       "purpose_of_transaction": "PROPERTY_PURCHASE"
14     }
15   }
16 ]

New Structure (Required):

1 "recipient_details": [
2   {
3     "amount": {
4       "currency": "AED",
5       "value": 3000.25
6     },
7     "payment_reference": "RentAug",
8     "purpose_of_transaction": "PROPERTY_PURCHASE",
9     "recipient_id": "123456"
10   }
11 ]

API Reference Updates

Create Payment Session - Updated request structure
Add a New Recipient - Required before creating sessions
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.

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

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 & Update a Recipient’s 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:
```
1 "additional_details": {
2   "tax_id": "AH12345678"
3 }
```
- 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 & Get Recipient Details

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.

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

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

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.

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

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)
`GET /v1/customers/{customer_id}/payments`	List Payments (v3)
`GET /v1/customers/{customer_id}/payments/{payment_id}`	Get Payment Details (v3)

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: Complete guide covering CoP verification errors and their corresponding resolution workflows for UK payments.
Verification of Payee (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 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:

1 {
2   "event_id": "3",
3   "event_timestamp": "2025-01-01T00:00:00Z",
4   "customer_id": "0201001008132685",
5   "client_customer_ref": "CUST_001",
6   "status": "APPROVED"
7 }

Documentation: See Third Party Customer Webhook Events for integration details and setup instructions.

Bug Fixes

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: Overview of Redpin’s APIs and core payment workflows
Making Your First Payment: Step-by-step tutorial for processing test payments
Error Handling: Best practices for handling API errors and implementing retry logic
Integration Guidelines: Complete guide for partners choosing integration approaches
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.

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.

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

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

Summary

New Features

Recipient ID-Based Payment 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 before creating a session

Enhanced Hosted Integration Workflow

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.

Migration Steps

Create Recipients First: Use the Add a New Recipient API to create recipients with their bank details
Store Recipient IDs: Save the recipient_id returned from the recipient creation response
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):

1 "recipient_details": [
2   {
3     "amount": {
4       "currency": "AED",
5       "value": 3000.25
6     },
7     "recipient": {
8       "name": "John Doe",
9       "type": "Individual",
10       "payment_reference": "RentAug",
11       "address": { ... },
12       "recipient_bank_details": { ... },
13       "purpose_of_transaction": "PROPERTY_PURCHASE"
14     }
15   }
16 ]

New Structure (Required):

1 "recipient_details": [
2   {
3     "amount": {
4       "currency": "AED",
5       "value": 3000.25
6     },
7     "payment_reference": "RentAug",
8     "purpose_of_transaction": "PROPERTY_PURCHASE",
9     "recipient_id": "123456"
10   }
11 ]

API Reference Updates

Create Payment Session - Updated request structure
Add a New Recipient - Required before creating sessions
Integration Guidelines - Updated workflow documentation

1	"recipient_details": [
2	{
3	"amount": {
4	"currency": "AED",
5	"value": 3000.25
6	},
7	"recipient": {
8	"name": "John Doe",
9	"type": "Individual",
10	"payment_reference": "RentAug",
11	"address": { ... },
12	"recipient_bank_details": { ... },
13	"purpose_of_transaction": "PROPERTY_PURCHASE"
14	}
15	}
16	]

1	{
2	"event_id": "3",
3	"event_timestamp": "2025-01-01T00:00:00Z",
4	"customer_id": "0201001008132685",
5	"client_customer_ref": "CUST_001",
6	"status": "APPROVED"
7	}

1	"additional_details": {
2	"tax_id": "AH12345678"
3	}

1	"additional_details": {
2	"tax_id": "AH12345678"
3	}