Readonly
httpTimeout 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
Cancel Invoice. This is a blocking operation. It will not return until the Requestor has acknowledged cancelling the Invoice or timeout has passed. The Requestor may refuse to cancel the Invoice if they have already accepted it.
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
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
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 receiving payments.
any OK
ApiError
Issue a Debit Note.
Readonly
agreementReadonly
debitReadonly
issuerReadonly
payeeReadonly
payerOptional
paymentReadonly
paymentOptional
Readonly
previousReadonly
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: stringOptional
usageany 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
Send Debit Note to Requestor. This is a blocking operation. It will not return until the Requestor has acknowledged receiving the Debit Note or timeout has passed.
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
Send Invoice to Requestor. This is a blocking operation. It will not return until the Requestor has acknowledged receiving the Invoice or timeout has passed.
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
Cancel Debit Note. WARNING: Operation not implemented.
This is a blocking operation. It will not return until the Requestor has acknowledged cancelling the Debit Note or timeout has passed. The Requestor may refuse to cancel the Debit Note if they have already accepted it.