Receiver testing

RippleNet members that receive payments conduct “receiver tests” by connecting to a Test Harness environment that simulates a payment sender or originator.

Payment receivers use the Test Harness to build and validate their RPO schema. In passive mode, the Test Harness can submit single payments or batch payments. Batch payments are supported in either JSON or CSV format.

Clearing partners receive test payments from a mock sending bank

Receiving Test Harness Architecture

Passive mode

Single payment

The Single Payment tab includes one pre-populated payment to send to your RippleNet Server deployment.

When you click Submit Payment with the default values, a quote is automatically requested and accepted; then a payment is created and sent for you to lock or reject.

You can enable Test Harness to automatically settle the payment by enabling "Auto Settle Locked Payments" under the Settings tab.

Auto Settle Locked Payment

You can also update the default RPO schema in "Supporting Info" by changing "Default Supporting Info" under the Settings tab.

Default Supporting Info

The Single Payment page includes the following fields:

Attribute Description Default Value
Sender Sender RippleNet Address trans_account@host

(configured during provisioning)
Receiver Receiver RippleNet Address username@host

(host configured during provisioning, change username to receiver account)
Amount Value to send (comma-separated or decimal) 105
Currency Sender's medium of exchange sender currency

(configured during provisioning)
Quote Type Indicates how to calculate payment quotes. Valid values are:

  • SENDER_AMOUNT
  • RECEIVER_AMOUNT
  • SENDER_INSTITUTION_AMOUNT
  • RECEIVER_INSTITITUION_AMOUNT

 SENDER_AMOUNT
Sending Fee Fees charged by the sender 0.02
Iterations Number of times to repeat payment 1
Test Case ID Arbitrary number to identify test TC-001
Payment Object Values that populate additional_info or user_info during Accept quote {
"ChrgBr": "SHAR",
"Cdtr": {
"Id": "8675309",
"Nm": "Jenny"
},
"Dbtr": {
"Id": "2675309",
"Nm": "Peter"
}
}

Batch payments

Batch payments can be tested with a payment template set (CSV file) that you upload to Test Harness (under Test Content). To run batch payments, choose from an existing payment Template Set:

Payment Template Set for Passive Receiver Tests

Or upload a payment template set CSV file directly into the Batch Payments UI:

Batch Payments as CSV File

Payment template sets are defined in CSV format, which uses commas to separate values. In a payment template set, quote parameters are nested under the quote object, and the user_info data is nested under the json object.

Batch payments must be submitted with the following required fields:

Field Required Optional Description
test_case_id x Arbitrary string to identify test case
quote.sending_address x Sender's host address
quote.receiving_address x Receiver's host address
quote.amount x Amount to send or receive, depending on quote.quote_type
quote.currency x Sender's medium of exchange
quote.quote_type x Indicates how to calculate quote values

Batch payments can also be submitted with the following optional fields:

Field Required Optional Description
end_to_end_id x Any value such as a randomly-generated UUID
iterations x Number of times to repeat payment/test
quote.* x Any quote parameter supported by RippleNet (For more information, see Create a Quote Collection in the RippleNet Server API reference)
json.* x Values that populate additional_info or user_info during Accept quote
resubmission x Active Receiver tests only: By default, resubmission=FALSE. To RETRY_ACCEPT a payment, set resubmission=TRUE
sub_id x Active Receiver tests only: By default, sub_id=0. For a RETRY_ACCEPT action, sub_id refers to the next available "resubmission" rows that should be used in ascending order until the payment is LOCKED or no more rows are available
Caution

The Test Harness is hosted and not a load testing tool.

Below is a CSV file for a sample payment, where <SENDER_HOST> and <RECEIVER_HOST> are placeholders:

Copy
Copied!
test_case_id,sub_id,resubmission,end_to_end_id,quote.amount,quote.receiving_address,quote.sending_address,quote.currency,quote.quote_type,quote.custom_fee,json.ChrgBr,json.Cdtr.StrdNm.FirstNm,json.Cdtr.StrdNm.LastNm,json.CdtrAcct.Id.Othr.Id,json.CdtrAgt.FinInstnId.ClrSysMmbId.MmbId,json.Dbtr.PstlAdr.AdrLine[0],json.Dbtr.PstlAdr.AdrLine[0],json.Dbtr.PstlAdr.Ctry,json.Dbtr.PstlAdr.CtrySubDvsn,json.Dbtr.PstlAdr.PstCd,json.Dbtr.PstlAdr.TwnNm,json.Dbtr.StrdNm.FirstNm,json.Dbtr.StrdNm.LastNm,json.PmtTpInf.CtgyPurp.Prtry
2.2,0,FALSE,RANDOM_NODASH_UUID,220,<RECEIVER_HOST>,<SENDER_HOST>,USD,sender_amount,1,CRED,Michael,Scott,12345678,BAD666,Dunder Mifflin Paper,1725 Slough Avenue Ste 200,USA,PA,18503,Scranton,Bob,Vance,DMINFINITY

Payments within a single batch can have different RPO structures. In this case, the header row is a superset for all payments in the batch. If a payment does not use one of the fields in the header row, that slot should be left blank, for example: value1,value2,,value4.

JSON batch format

For quick testing, you can send a batch of default test payments based on a JSON-formatted payment template set. You can paste your own JSON payments over the existing defaults:

Batch Payments as JSON File

This is one of the default payments in the array, where <SENDER_HOST> and <RECEIVER_HOST> are placeholders:

Copy
Copied!
{
  "test_case_id": "RNTC-1.2",
  "end_to_end_id": "RANDOM_NODASH_UUID",
  "iterations": 1,
  "json": {
    "new_rpo_field": "description of new field"
  },
  "quote": {
    "sending_address": "<SENDER_HOST>",
    "amount": "100",
    "receiving_address": "<RECEIVER_HOST>",
    "custom_fee": "5",
    "currency": "USD",
    "quote_type": "SENDER_AMOUNT"
  }
}

Active mode

Payment receiving institutions can create an active test one of two ways: by selecting a pre-loaded test profile and payment template set or by uploading a RippleNet project workbook which generates these artifacts.

Test profiles

To create an active mode test with a test profile, you first upload a test profile and payment template set under test content. Then you select the profile and payment set when creating the test.

Active tests are dependent on test case IDs matching in the profile and payment set. For example, if your test profile defines three test case IDs (1.01, 1.02, and 1.03), and you use the following (truncated) payment set, tests 1.01 and 1.02 run with the DEFAULT payment data as nothing is defined for 1.01 and 1.02. Test Case 1.03 uses the payment record with the matching ID.

Copy
Copied!
        test_case_id,sub_id,type,end_to_end_id,quote.amount, ...
        DEFAULT,0,ORIGINAL,RANDOM_NODASH_UUID,1000, ...
        1.03,0,ORIGINAL,RANDOM_NODASH_UUID,103, ....

For details, see Run active mode receiver tests.

Project workbooks

You can generate a test profile and payment template by importing a spreadsheet (RippleNet Project Workbook) with test data. You can also create a test on-the-fly with this data and either save it or run it.

Create project workbook

Your project workbook must have one tab that defines the RPO fields (per currency and corridor) and one that defines payment values.

  1. Copy and paste the RPO and payment sample data below into a spreadsheet and save locally as THWB Receiver Test Data (US R123).xlsx .
  2. Edit the payment data by replacing <RECEIVER_ADDRESS> and <SENDER_ADDRESS> with the proper sending and receiving RippleNet addresses.
  3. Copy and paste and save the test profile locally as thwb_recvtest_test_profile_R123.json

Active Test from Workbook

RPO Fields

Copy
Copied!
|	RPO Grouping |	RPO Field					|	Ripple Field Definition  (for latest refer to RNR documentation)																													        |   Type    | Maximum Length |	Required	|	Condition (if any)											 	|	Format									| Supported Values  |	Error Codes (ISO20022)	|	Valid Data				|	Invalid Data	| Non-Compliant Data|	Example / Sample Value	|EXPORT TO JSON	|
|:---------------|:-----------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:----------|:---------------|:-------------|:------------------------------------------------------------------|:------------------------------------------|:------------------|:--------------------------|:--------------------------|:------------------|:------------------|:--------------------------|:--------------|
|				 |	end_to_end_id				|	Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain.	|	String	|	128        	 |	Mandatory	|																	|	Payment reference						|					|	A0110					|	ABC123					|	Invalid_E2E		|	NonComp_E2E		|	ABC123					|	Mandatory	|
|				 |	Cdtr.Nm						|	Name by which the party is known and which is usually used to identify the party.																											|	String	|	50			 |	Mandatory	|																	|	Full name of individual or organization	|					|	RN0013					|	John Arthur Doe			|	InValid_Nm		|	NC_Nm			|	John Arthur Doe			|	Mandatory	|
|				 |	Cdtr.CtryOfRes				|	Country of Residence of the individual or organization																																		|	String	|	2			 |	Mandatory	|																	|	ISO 3166-1 alpha-2						|					|	XC0149					|	DE						|	InVal_Ctry		|	NC_Ctry			|	DE						|	Mandatory	|
|				 |	CdtrAcct.Id.IBAN			|	Holds the IBAN for the account																																								|	String	|	31			 |	Mandatory	|																	|	IBAN									|					|	RN0000					|	DE91100000000123456789	|	Invalid_IBAN	|	NC_IBAN			|	DE91100000000123456789	|	Mandatory	|
|				 |	CdtrAgt.FinInstnId.BICFI	|	Code allocated to a receiving institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identifier code (BIC)"	|	String	|	11			 |	Mandatory	|																	|	SWIFT code								|					|	RN0013					|	DEUTDEFF				|	TR_BIC			|	OS_BIC			|	DEUTDEFF				|	Mandatory	|
|				 |	UltmtDbtr.PstlAdr.AdrLine	|	Information that locates and identifies the address for the party.																															|	Array	|	256			 |	Mandatory	|	Combined length of address lines cannot exceed 256 characters.	|											|					|	XC0149					|	SG_ULT_DBT_ADDR			|	TR_ULT_DBT_ADDR	|	OS_ULT_DBT_ADDR	|							|	Mandatory	|

Payment Template

Copy
Copied!
| test_case_id | end_to_end_id      | quote.amount | quote.sending_address | quote.receiving_address | quote.currency | quote.quote_type          | quote.custom_fee |
|:-------------|:-------------------|:-------------|:----------------------|:------------------------|:---------------|:--------------------------|:-----------------|
| default      | RANDOM_NODASH_UUID | 1000         | <SENDER_ADDRESS>      | <RECEIVER_ADDRESS>      | USD            | sender_amount             | 0.01             |
| R1           |                    | 111          |                       |                         |                | sender_institution_amount | 10               |
| R2           |                    | 112          |                       |                         |                |                           | 10               |
| R3           |                    | 103          |                       |                         |                |                           | 0                |

Test Profile

Create workbook test

  1. Log on to the Test Harness that sends payments (to run your receiver tests).
  2. Click Receiver Tests > Active Mode .
  3. Click New Test to open a popup and select From Project Workbook .

    New Workbook Test

  4. In the dialog, select the Workbook, RPO tab, Payments tab, and Test Profile.
  5. Click Download Test Files to download a Test Profile with one test per RPO field (in this case 16) and a Payment Template file in .csv format.
  6. Click Save Test to save the test for future runs.
  7. Click Run Test to run the test.

One or more tests are created per RPO field. The workbook data included here generates 16 tests.

Workbook Test Dialog