Change history

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.

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.

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.

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

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

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.

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:

For more information on the reconciliation report, see 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.

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

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.

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.

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.

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.

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:

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

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

API enhancement summary

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.

New authentication proxy URL

We've updated the Cloud 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

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:

  Copy

  Copied!

  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:

  Copy

  Copied!

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

  Copy

  Copied!

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

  Copy

  Copied!

  "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 and Get liquidations by payment Id.

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

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.