Amounts are adjusted based on the destination/outgoing account’s asset and Rafiki’s configured exchange rates service.
The connector receives incoming ILP packets via:
- direct calls from within the
backend includes an HTTP server listening on the configured
An incoming ILP packet over HTTP is only accepted if it is from a configured peer and accompanied by the peer’s incoming HTTP
backend includes services for managing Open Payments quotes and outgoing payments. Each of these calls the connector in order to send ILP packets. Quoting sends unfulfillable rate probe packets. Outgoing payments send packets as a part of executing the payment.
These calls to the connector are actually made by calling
makeIlpPlugin and passing the plugin to the
An ILP packet may either terminate at the local Rafiki’s STREAM server or continue on to a peer via HTTP.
Local STREAM Server
The connector attempts to extract and decode the payment tag from a received ILP packet’s destination address. If it is successfully able to match the tag with a locally managed Open Payments payment pointer or incoming payment, it will not forward the packet. The connector will credit the corresponding balance as well as track the total amount received for the STREAM connection in Redis in order to support STREAM receipts.
Packets addressed to a payment pointer happen via SPSP.
If the ILP packet’s destination address corresponds to a configured peer, the connector will forward the packet to the peer over HTTP along with the peer’s configured HTTP
The connector may reject a packet with a corresponding ILP error code due to a number of reasons:
- invalid packet
- insufficient liquidity
- rate limit exceeded
- amount exceeding
- expired packet