Readonly
httpOptional
autoTimeout used in blocking calls waiting for eg. acknowledgement. How many seconds server should wait for response/acknowledgement of an action (0.0 means it should wait for other party's response indefinitely)
any OK
ApiError
Accept received Invoice. Send Invoice Accepted message to Invoice Issuer. Trigger payment orchestration for this Invoice using specified Allocation.
This is a blocking operation. It will not return until the Requestor has acknowledged rejecting the Invoice or timeout has passed.
NOTE: An Accepted Invoice cannot be Rejected later.
Timeout used in blocking calls waiting for eg. acknowledgement. How many seconds server should wait for response/acknowledgement of an action (0.0 means it should wait for other party's response indefinitely)
any OK
ApiError
Amend Allocation.
Optional
deposit?: { Optional
validate?: Record<string, any>Optional
timeout?: stringOptional
totalany OK
ApiError
Create Allocation. Allocate funds to make sure they are not spent elsewhere.
Optional
address?: stringReadonly
allocationOptional
deposit?: { Optional
validate?: Record<string, any>Optional
extendin seconds, the time by which the allocation timeout is extended after it is last used.
Optional
makeOptional
paymentReadonly
remainingReadonly
spentOptional
timeout?: stringReadonly
timestamp: stringOptional
afterTimestamp: stringApply only to records created later than the specified timestamp
Maximum number of items that server should return at once.
any OK
ApiError
Get Allocation.
any OK
ApiError
Get Allocations.
any OK
ApiError
Get Debit Note.
any OK
ApiError
Get Debit Note events.
Listen for Debit Note-related events using long-polling. If there are any events the method will return them immediately. If there are none the method will wait until one appears or timeout passes. afterTimestamp
parameter can be used in order to get just the 'new' events. Setting the parameter value to the timestamp of the last processed event ensures that no events will go unnoticed.
NOTE: The events are persistent, ie. calling the API does not remove the event records from receiving queue.
Timeout used in long-polling calls (in seconds). How many seconds server should wait for response containing new events (0.0
means it should return immediately if there are no events)
Optional
afterTimestamp: stringApply only to records created later than the specified timestamp
Maximum number of events that server should return at once.
Optional
appSessionId: stringA correlation/session identifier used for querying events related to an action where this appSessionId has been specified
any OK
ApiError
Get Debit Notes known by this node (either issued by this Provider or received by this Requestor).
Optional
afterTimestamp: stringApply only to records created later than the specified timestamp
Maximum number of items that server should return at once.
any OK
ApiError
Obtain Demand elements specific to the given allocations, to be appended to a market Demand. Generate payment-related properties and constraints to be added to a demand published on the marketplace. As a parameter it accepts a list of IDs of allocations to be used to pay for invoices resulting from the decorated demand.
any OK
ApiError
Get Invoice.
any OK
ApiError
Get Invoice events.
Listen for Invoice-related events using long-polling. If there are any events the method will return them immediately. If there are none the method will wait until one appears or timeout passes. afterTimestamp
parameter can be used in order to get just the 'new' events. Setting the parameter value to the timestamp of the last processed event ensures that no events will go unnoticed.
NOTE: The events are persistent, ie. calling the API does not remove the event records from receiving queue.
Timeout used in long-polling calls (in seconds). How many seconds server should wait for response containing new events (0.0
means it should return immediately if there are no events)
Optional
afterTimestamp: stringApply only to records created later than the specified timestamp
Maximum number of events that server should return at once.
Optional
appSessionId: stringA correlation/session identifier used for querying events related to an action where this appSessionId has been specified
any OK
ApiError
Get Invoices known to this node (either issued by this Provider or received by this Requestor).
Optional
afterTimestamp: stringApply only to records created later than the specified timestamp
Maximum number of items that server should return at once.
any OK
ApiError
Get Payment.
any OK
ApiError
Get Payments.
Payments can be treated as events and this method can be used to listen for new payments by long-polling. If there are any payments the method will return them immediately. If there are none the method will wait until one appears or timeout passes. afterTimestamp
parameter can be used in order to get just the 'new' payments. Setting the parameter value to the timestamp of the last processed payment ensures that no payments will go unnoticed. network
and driver
parameters can be used in order to filter payments.
Timeout used in long-polling calls (in seconds). How many seconds server should wait for response containing new events (0.0
means it should return immediately if there are no events)
Optional
afterTimestamp: stringApply only to records created later than the specified timestamp
Maximum number of events that server should return at once.
Optional
appSessionId: stringA correlation/session identifier used for querying events related to an action where this appSessionId has been specified
Optional
network: stringNetwork identifier used for filtering payments made via the specified network
Optional
driver: stringDriver identifier used for filtering payments made with the selected driver
any OK
ApiError
Optional
afterTimestamp: stringApply only to records created later than the specified timestamp
Maximum number of items that server should return at once.
any OK
Get Payments for Debit Note. WARNING: Operation not implemented.
ApiError
Optional
afterTimestamp: stringApply only to records created later than the specified timestamp
Maximum number of items that server should return at once.
any OK
Get Payments for Invoice. WARNING: Operation not implemented.
ApiError
Get available accounts for sending payments.
any OK
ApiError
Issue an Invoice.
Optional
activityReadonly
invoiceReadonly
issuerReadonly
payeeReadonly
payerReadonly
paymentReadonly
recipientReadonly
status: "ISSUED" | "RECEIVED" | "ACCEPTED" | "REJECTED" | "FAILED" | "SETTLED" | "CANCELLED"Accepted status indicates that the Requestor confirms the Amount/Total Amount Due on the Invoice/Debit Note, respectively. The Payment API Implementation is expected to proceed with the orchestration of the payment. Internals of the payment processing (e.g. payment processing internal states) are specific to the selected Payment Platform, and must be indicated as an attribute of the Accepted status. However, as they are specific - they shall not be standardized by the Payment API.
A Rejected Invoice/Debit Note can subsequently be Accepted.
An Accepted Invoice/Debit Note cannot be subsequently Rejected.
There is a difference between Paid and Settled - depending on a Payment Platform. Paid indicates that the Requestor has ordered Payments of Total Amount Due as indicated by received/accepted Debit Notes/Invoice. Settled indicates that the Provider has reliably received the Payments.
WARNING: 'Paid' status currently not implemented.
Readonly
timestamp: stringany OK
ApiError
Get status of the payment driver This only relates to the erc20 driver, not erc20legacy. The returned list contains individual status properties, which can be used to identify problems like missing funds or misconfigured max fee per gas on a per-chain (network) basis.
Optional
network: stringNetwork identifier used for filtering payments made via the specified network
Optional
driver: stringDriver identifier used for filtering payments made with the selected driver
any OK
ApiError
Reject received Debit Note. WARNING: Operation not implemented.
Send Debit Note Rejected message to Invoice Issuer. Notification of rejection is signalling that Requestor does not accept the Debit Note (for some reason).
This is a blocking operation. It will not return until the Requestor has acknowledged rejecting the Invoice or timeout has passed.
NOTE: A Rejected Debit Note can be Accepted subsequently (e.g. as a result of some arbitrage).
Optional
message?: stringPossible reasons to reject a Debit Note or Invoice.
Timeout used in blocking calls waiting for eg. acknowledgement. How many seconds server should wait for response/acknowledgement of an action (0.0 means it should wait for other party's response indefinitely)
any OK
ApiError
Reject received Invoice. WARNING: Operation not implemented.
Send Invoice Rejected message to Invoice Issuer. Notification of rejection is signalling that Requestor does not accept Invoice (for some reason).
This is a blocking operation. It will not return until the Requestor has acknowledged rejecting the Invoice or timeout has passed.
NOTE: A Rejected Invoice can be Accepted subsequently (e.g. as a result of some arbitrage).
Optional
message?: stringPossible reasons to reject a Debit Note or Invoice.
Timeout used in blocking calls waiting for eg. acknowledgement. How many seconds server should wait for response/acknowledgement of an action (0.0 means it should wait for other party's response indefinitely)
any OK
ApiError
Release Allocation. The Allocation of amount is released. Note that this operation releases currently allocated amount (which may have been reduced by subsequent Invoice Payments).
WARNING: Deposits not implemented.
If the Allocation was connected with a Deposit the release amount from Deposit shall be marked as pending to be paid back to Requestor - and eventually will be paid back, unless a subsequent Allocation with Deposit is made. The Payment Platform implementations may optimize unnecessary fund transfers (i.e. will not pay back the Deposit if released funds can be assigned to a new Allocation with Deposit).
any OK
ApiError
Accept received Debit Note. Send Debit Note Accepted message to Debit Note Issuer. If Debit Note is binding (i.e. has non-null payment due date) trigger payment orchestration for this Debit Note using specified Allocation.
This is a blocking operation. It will not return until the Requestor has acknowledged accepting the Invoice or timeout has passed.
NOTE: An Accepted Debit Note cannot be Rejected later.