# Change history This page summarizes notable changes made to RippleNet. This change history is arranged in order from the most recent change and it corresponds to the month and year the enhancements and fixed issues were made available. ## April 2025 details summary Click to expand changes ### Enhancements The following new and enhanced functionality is delivered as part of this release: **Quotes available for stablecoin sending currencies** When you create a payment, you can now specify stablecoin, such as USDT, as the sending currency for the quote. ## December 2024 details summary Click to expand changes ### Enhancements The following new and enhanced functionality is delivered as part of this release: **Option to configure delay for delivering funds from the SSA** For reconciliation purposes, receivers can now request their Customer Partner Engineers (CPE) to configure a delay for delivering funds from a Sender Segregated Account (SSA) to the beneficiary. For more information on a payment flow with SSA, see also [Sender Segregated Account](/products/payments-odl/api-docs/ripplenet/system-components/failure-conversion-and-ssa/sender-segregated-account). ## July 2024 Report API format changes The Reporting API response format has changed to support future development. details summary Click to expand changes Old format ```json { "reports": [ { "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08", "type": "PAYMENT_OPS", "format": "CSV", "status": "READY", "start_date": "2018-04-06T20:33:35Z", "end_date": "2018-04-06T20:33:35Z" } ] } ``` New format ```json { "reports": [ { "reportId": "497f6eca-6276-4993-bfeb-53cbbbba6f08", "reportName": "My custom report", "reportType": "PAYMENT_OPS", "reportFormat": "CSV", "reportStatus": "READY", "startDate": "2018-04-06T19:33:35Z", "endDate": "2018-04-06T20:33:35Z", "createdOn": "2018-04-06T20:33:35Z" } ] } ``` details summary Click to expand changes ### Enhancements The following new and enhanced functionality is delivered as part of this release: **Report Service API** - Batch payments are now included in reports. - Create ad-hoc reports using the [Create a report](/products/payments-odl/api-docs/report_service/reference/openapi/reports/postreport) API operation. **Support of live exchange rates** When you make a `Create rate` or `Update rate` request for a new SSA payment or a fiat payment, you can now choose to use either a live exchange rate or a rate manually configured by Ripple. To make your selection, you must specify the rate's `value_type` and, depending on that value, also the `margin_type`. For more information, see [Create rate](/products/payments-odl/api-docs/ripplenet/reference/openapi/rates/createrate) and [Update rate](/products/payments-odl/api-docs/ripplenet/reference/openapi/rates/updaterate). ## April 2024 details summary Click to expand ### Fixed issues The following are high-priority fixed issues included in this change: **Race condition in RippleNet `/settle` operation when called twice for the same payment** Previously, when you called the RippleNet `/settle` operation twice for the same payment, a race condition occurred which resulted in double debit entries on the ledger account. This is now fixed and when you call the `/settle` operation twice for the same payment, you'll see an error message instead of a double debit entry. ## March 2024 New portal The new Ripple Payments documentation set launched. ## October 2023 details summary Click to expand ### Enhancements The following new and enhanced functionality is delivered as part of this patch release: **Launch of Exchange Payout service** Ripple's new Exchange Payout service supports automatic payout from certain exchanges to the beneficiary's bank account. You can conveniently select the beneficiary from a drop-down list in the Ripple Payments UI. For more information, see [New payment form](/products/payments-odl/user-interface/payments/new-payment-form#quote-review-form). ## September 2023 details summary Click to expand ### Enhancements The following new and enhanced functionality is delivered as part of this change: **Error type `QUOTE_INELIGIBLE_TO_ACCEPT` contains new error scenario** The [RippleNet Server payments error](/products/payments-odl/api-docs/ripplenet/resources/error-codes/ripplenet-server-error-codes#payments-errors) `QUOTE_INELIGIBLE_TO_ACCEPT` (PY0012) now contains the following new error scenario: - `{Tenant} exceeded limit`The quote can't be accepted because the tenant has exceeded their credit limit. ## August 2023 details summary Click to expand ### Enhancements The following new and enhanced functionality is delivered as part of this change: **Error type `QUOTE_INELIGIBLE_TO_ACCEPT` contains new error scenarios** The [RippleNet Server payments error](/products/payments-odl/api-docs/ripplenet/resources/error-codes/ripplenet-server-error-codes#payments-errors) `QUOTE_INELIGIBLE_TO_ACCEPT` (PY0012) now contains the following two new error scenarios: - `{Tenant}'s account is past due. Please contact customer support. If you have submitted confirmation of your payment, please stand by.` The quote can't be accepted because the tenant is blocked by Finance. - `{Tenant}'s payment is blocked due to risk. Please contact customer support.` The quote can't be accepted because the tenant is either blocked by Risk, Compliance, or Legal. ## July 2023 details summary Click to expand ### Enhancements The following new and enhanced functionality is delivered as part of this change: **Fail RippleNet Server deployment for mismatched schemas** Previously, your database's schema version wasn't checked at the time of the RippleNet Server application deployment. Sometimes, this caused invalid combinations of application and database to be deployed. This has now changed and the database schema version gets validated and in case of a mismatch with the application, the application deployment then fails. ## June 2023 details summary Click to expand ### Enhancements The following new and enhanced functionality is delivered as part of this change: **Reconciliation report includes new data fields** The reconciliation report, used for reconciliation and state-by-state investigation, now has the following new data fields: | Data field | Description | | --- | --- | | `withdrawal_result_details_transaction_id` | The ID of the payment or transfer that caused an account balance change | | `destination_result_id` | The UID of the destination trade at the destination exchange | For more information on the reconciliation report, see [Reconciliation report](/products/payments-odl/user-interface/payments/payment-reports#reconciliation-report). ### Fixed issues The following are high-priority fixed issues included in this change: **Race condition in RippleNet `/settle` operation when called twice for the same payment** Previously, when you called the RippleNet `/settle` operation twice for the same payment, a race condition occurred which resulted in double debit entries on the ledger account. This is now fixed and when you call the `/settle` operation twice for the same payment, you'll see an error message instead of a double debit entry. **Payment state updates before `user_info` field is populated in RPO** Previously, the payment state was updated before the `user_info` field was populated in the RippleNet Payment Object (RPO). This caused users to poll payments with an `ACCEPTED` state which showed an empty `user_info` field. This is now fixed and the `user_info` is saved before the payment state is updated to `ACCEPTED`. **Payment details show `SETTLEMENT_DECLINED` but payment is completed** Previously, the payment details in the event trail of the payment showed `SETTLEMENT_DECLINED` even though the payment state was `COMPLETE`. This is now fixed and a complete payment no longer shows `SETTLEMENT_DECLINED` in the event trail. ## May 2023 details summary Click to expand ### Enhancements The following new and enhanced functionality is delivered as part of this change: **`FAILED` state timestamp added to RPO** Previously, the RippleNet Payment Object (RPO) didn't contain a timestamp for when a payment went into `FAILED` state. This is now changed and support for the `failed_at` timestamp is now available in the RPO. For more information on the RPO, see [Standard RippleNet Payment Object (SRPO)](/products/payments-odl/api-docs/ripplenet/resources/standard-ripplenet-payment-object). ### Fixed issues The following are high-priority fixed issues included in this change: **Intermittent empty quote responses** Previously, when you requested a quote, RippleNet intermittently returned empty quote responses. This is now fixed and RippleNet always returns a quote. ## March 2023 details summary Click to expand ### Enhancements The following new and enhanced functionality is delivered as part of this change: **Report Service API** The Report Service API provides an efficient and secure way to download On-Demand Liquidity (ODL) payment transactions on the RippleNet network. The following two report types are available in either CSV or JSON format: - Basic payment report (`PAYMENT_OPS`) - This report is suitable for high-level payment investigation and reporting. The report provides basic payment data, but not transaction data within payments. - Reconciliation report (`RECON`) - This report is suitable for reconciliation and detailed state-by-state investigation. The report provides all basic payment data, but also trade and liquidation data that may be associated with a payment. For more information about the Report Service API, see [Report Service API](/products/payments-odl/api-docs/report_service/reference/openapi). ## October 2022 New site RippleNet Documentation Version 3.0 launched! ## August 2022 details summary Click to expand ### Enhancements The following new and enhanced functionality is delivered as part of this change: **ODL flag config can now be enabled for sender and exchange together** Previously, you could enable the ODL flag config for either exchange or sender, but not both. The ODL flag config logic returned only the first configuration it encountered. This is now changed and you can enable the configuration for both sender and exchange together. **Removed unnecessary ODL property check** Removed the property check that determines whether RippleNet passes the configuration flag `PARTIAL_PAYMENTS_BENEFICIARY_ACCOUNT`. The value passed by this flag is mandatory for FX-with-margin calculation, without which ODL can't apply the configured incentives. We no longer need to check the property. ### Fixed issues The following are high-priority fixed issues included in this change: **The Accept Quote operation called twice for the same quote ID** Previously, if RippleNet received multiple **Accept quote** requests simultaneously, it was possible for separate payments to be created with the same quote ID. If the first of these payments completed, the remaining payments might get stuck. This is now fixed by code in RippleNet to prevent the **Accept quote** operation from running more than once on the same quote ID. RippleNet now returns a `400` error code for the duplicate requests. For more information on the `Accept quote` operation, see [Accept quote](/products/payments-odl/api-docs/ripplenet/reference/openapi/quotes/acceptquote). **Multiple retries of primary job, when secondary job failed** Fixed problem where RippleNet retried an entire job multiple times, whenever a secondary job failed. Also added logic to prevent duplicate Sender Segregated Account (SSA) transfer fundings from happening when retrying the job if a transfer was already executed for the payment. ## April 2022 details summary Click to expand ### Enhancements The following new and enhanced functionality is delivered as part of this change: **Get Account Statement now returns sender and receiver addresses** New `sender_address` and `receiver_address` fields were added to the JSON response from the Get Account Statement API. Previously, the Get Account Statement API didn't return enough information to determine who sent payments, how many were sent, and how many got liquidated. The `sender_address` and `receiver_address` fields are now included in the returned JSON response, and populated whenever possible. *Example response for a PAYMENT transaction type:* ```http { "transaction_id": "51405ec1-edbd-4953-aefe-5f2178ab6cf0", "transaction_type": "PAYMENT", "transaction_state": "EXECUTED", "balance_change": "9999.99000000", "balance_result": "32456.51000000", "created_at": "2021-12-17T03:58:45.528Z", "end_to_end_id": "03915", "internal_id": "a5ab9e7d-731a-4b2b-84f4-05e4a2f570dd", "venue_id": "074aad75-cade-4aa0-90eb-d20a10376c39", "transaction_hash": "b9bd8018-754e-4a78-9351-ab3e08fecd4d", "returns_payment_with_id": null, "returned_by_payment_with_id": null, "balance_change_created_at": "2021-12-17T03:58:45.528Z", "sender_address": "rn.hkg.mycorp", "receiver_address": "rn.sgp.othercorp" } ``` *Example response for a TRANSFER transaction type:* If executing a withdrawal or funding with the Transfer transaction type, the `sender_address` and `receiver_address` fields can be either null or the RippleNet address of the originating node. ```http { "transaction_id": "51405ec1-edbd-4953-aefe-5f2178ab6cf0", "transaction_type": "TRANSFER", "transaction_state": "EXECUTED", "balance_change": "9999.99000000", "balance_result": "32456.51000000", "created_at": "2021-12-17T03:58:45.528Z", "end_to_end_id": "03915", "internal_id": "a5ab9e7d-731a-4b2b-84f4-05e4a2f570dd", "venue_id": "074aad75-cade-4aa0-90eb-d20a10376c39", "transaction_hash": "b9bd8018-754e-4a78-9351-ab3e08fecd4d", "returns_payment_with_id": null, "returned_by_payment_with_id": null, "balance_change_created_at": "2021-12-17T03:58:45.528Z", "sender_address": null, "receiver_address": null } ``` For more information on the `Get Statement` operation, see [Get Statement](/products/payments-odl/api-docs/ripplenet/reference/openapi/balances-and-statements/getstatement). **API enhancement summary** | Action | Change | Feature | | --- | --- | --- | | Added | `sender_address` and `receiver_address` fields added to the `StatementRecord` object. | Get Account Statement now returns sender and receiver addresses | ## March 2022 details summary Click to expand ### Enhancements The following new and enhanced functionality is delivered as part of this change: **Enhanced Account Lookup API** The Account Lookup API includes the following enhancements: * **Initiate Account Lookup operation** The Initiate Account Lookup operation now accepts the following new optional input properties in the request body: - `account_currency` - `clearing_system_code` * **Complete Account Lookup operation** Previously, the `result_code` field in the request body of the Complete Account Lookup operation accepted one of three allowed values. This field now accepts any value specified in the format of `RNCBNNNN`, for example `RNCB0008`. Additionally, the Complete Account Lookup operation now accepts the following new optional input properties in the request body: - `redacted_account_currency` - `redacted_clearing_system_code` * **Get Account Lookups operation** You can now filter the results from the Get Account Lookup operation by date range by specifying `start-date` and `end-date` query parameters. Additionally, the `account_lookup_status` query parameter now accepts more than one allowed status value. Previously, this parameter only accepted one status value. For more information on the `Initiate account lookup` operation, see [Initiate account lookup](/products/payments-odl/api-docs/ripplenet/reference/openapi/beneficiary-confirmation/initiateaccountlookup). **New authentication proxy URL** We've updated the [Cloud Authentication](/products/payments-odl/api-docs/ripplenet/best-practices/authentication) documentation with new authentication proxy URLs. In the respective RippleNet Cloud environment, you can now send a `POST` request to the following endpoints: - **Test**: `https://auth-test.rnc.ripplenet.com/oauth/token` - **UAT**: `https://auth-uat.rnc.ripplenet.com/oauth/token` - **Production**: `https://auth.rnc.ripplenet.com/oauth/token` As the proxy caches the token, you no longer have to cache the token client-side for reuse. The `https://auth.eu.prod.ripplenet.net` URL is still supported, but will be retired at a future date. The authentication proxy URL of the RippleNet Cloud Production environment resolves to the following static IP addresses: * 35.178.226.20 * 13.40.239.203 * 18.169.92.119 Add these IP addresses to your allowlists or firewalls as needed. **API enhancement summary** | Action | Change | Feature | | --- | --- | --- | | Added | New input fields added. | Initiate Account Lookup operation | | Changed | Content validation rule for `result_code` field value changed. | Complete Account Lookup operation | | Changed | Filtering options enhanced. | Get Account Lookups operation | ## January 2022 details summary Click to expand Note Starting now, RippleNet Cloud is supported exclusively. The last supported version for RippleNet Server On-premises is 4.15. Previously supported additional databases Oracle, Microsoft SQL Server, and MySQL are no longer supported. ### Enhancements The following new and enhanced functionality is delivered as part of this change: **Sender Segregated Account configuration enhancements** The Sender Segregated Account configuration includes the following enhancements: * **Body parameter field added to Create SSA configuration operation** The `payment_sender_host` was added as an optional field to the request body parameter for the *Create SSA configuration* operation. By specifying the `payment_sender_host` field, the Sender can differentiate their Sender Segregated Account (SSA) configuration from other Sending partners' configuration who may be using the same liquidity path. *Example POST Create SSA Configuration request:* ```http POST https://sf-bank.ripplenet.com/v4/config/ssa_config HTTP/1.1 Authorization: Bearer eyJhbGciOiJIUzI1NiIsI......nR5cCI6IkpXVCJ9 { "ssa_account": "ssaaccount@peer.rn.address", "source_account": "source_account@peer.rn.address", "ssa_currency": "SGD", "payment_sender_host": "peer.rn.address" } ``` *Example POST Create SSA Configuration response:* ```http { "ssa_config_id": "573b7432-14c4-11ec-82a8-0242ac130003", "ssa_account": "ssaaccount@peer.rn.address", "source_account": "source_account@peer.rn.address", "ssa_currency": "SGD", "payment_sender_host": "peer.rn.address" } ``` * **RPO now returns SSA transfer status** The RippleNet Payment Object (RPO) now includes the status of fund transfers to the Sender's SSA. When the funds from a failed payment are transferred to the SSA, the information in the `json` object associated with the `settlement_declined` array in the `user_info` object indicates the status of the transfer. *Example response showing a successful SSA transfer:* ```http "user_info": [ { "node_address": "rn.us.ca.san_francisco", "settlement_declined": [ { "json": { "ssa_remote_transfer_id" : "00ba6533-10ec-4b0d-aa3d-db324b4c8e4f", "transfer_amount" : "10", "transfer_currency" : "PHP", "funding_account" : "source@receiver", "ssa_account" : "ssa@receiver", "transfer_state" : "EXECUTED" }, "created_at": "2021-07-08T22:46:41.62Z" }, ... ] } ] ``` *Example response showing a failed SSA transfer:* ```http "user_info": [ { "node_address": "dev.test.testing", "settlement_declined": [ { "json": { "message" : "SSA Funding failed.", "error": "sample error details", "title": "sample some detail" }, "created_at": "2021-07-08T22:46:41.62Z" }, ... ] } ] ``` * **Funds from Push Forward now liquidated and transferred to SSA** Previously, Wallet Receive funds that were credited by Push Forward remained in the wallet as XRP. Now, the XRP funds from a Push Forward transaction are liquidated to the destination fiat currency and transferred to the Sender's SSA held on the Receiver side. **RPO now returns ODL payment ID** Now, the `odl_payment_id` field is added to the `ExecutionResult` object, and is returned as part of the RPO. This is the payment ID for an executed On-Demand Liquidity payment containing the transaction corresponding to this execution result. For more information on the `odl_payment_id` field, see [Get liquidation by Id](/products/payments-odl/api-docs/smart_liquidation/reference/openapi/liquidations/getliquidationbyid) and [Get liquidations by payment Id](/products/payments-odl/api-docs/smart_liquidation/reference/openapi/liquidations/getliquidationsbyripplenetpaymentid). **Pathfinding cache TTL** The pathfinding TTL is increased to 43200000 ms (12 hours). Previously, the timing for optimized pathfinding was preset to 720 ms. **API enhancement summary** | Action | Change | Feature | | --- | --- | --- | | Added | `payment_sender_host` field added to the SSA Configuration Create Request object. | Sender Segregated Account | | Added | `odl_payment_id` field added to the `ExecutionResult` object. | RippleNet Payment Object | ### Fixed issues The following are high-priority fixed issues included in this change: **Fix liquidation status check to stop liquidation from repeating** Previously in Wallet Receive, XRP to fiat liquidation occurred twice instead of once for some payments in the `EXECUTED` status. This happened because the in-progress liquidation was erroneously marked as failed and was later successfully retried. When the in-progress liquidation eventually succeeded, it resulted in XRP being liquidated twice. This change fixes the issue. **`venue_id` not populated in RPO** Previously, for payment and liquidation execution results, the `venue_id` field in the `ExecutionResult` object returned a `null` value instead of the expected ID. This issue has been fixed.