Gets a payment request by its order ID.

The amount of money to request.

The currency of the request.

An optional customer identifier for the payment request.

An optional order ID for the payment request. If the request is for an invoice this is the most appropriate field for the invoice ID.

An optional description for the payment request. If set this field will appear on the transaction record for some card processors.

The payment account ID to use to receive payment initiation payments. This must match one of your NoFrixion payment account IDs. This can be left blank to use your default payment account.

For card payments the origin of the payment page needs to be set in advance. A public key context is generated to encrypt sensitive card details and is bound to a single origin URL.

Once a payment is processed, or a notification of an inbound payment is received, a callback request will be made to this URL. Typically it will be the page on a merchant's web site that displays the results of the payment attempt.

Optional callback URL for payment failures that can occur when the payer is redirected away from the payment page. Typically the payer is only sent away from the payment page for pay by bank attempts. If this URL is not set the payer will be redirected back to the original URL the payment attempt was initiated from.

If a payment event results in the payment request being classified as fully paid this success webhook URL will be invoked. The URL will be invoked as a GET request, i.e. there will be no request body. Two query parameters will be added to the URL. The first one will be "id" and will hold the payment request ID. The second one will be "orderid" and will hold the payment request OrderID, note the OrderID could be empty if it was not set when the payment request was created. The recommended approach when receiving a success web hook is to use the "id" parameter to call the moneymoov get payment request endpoint to retrieve the full details of the payment request and check the status. Web hooks can be easily spoofed and should not be relied upon.

For card payments the default behaviour is to authorise and capture the payment at the same time. If a merchant needs to authorise and then capture at a later point this property needs to be set to true.

For card payments a payment attempt can be used to create a reusable token for subsequent payments. Setting this field to true will create a reusable customer token.

This specifies whether user consent will be taken before tokenising card or not. If this is set to 'UserConsentRequired' then, the user consent will potentially update CardCreateToken flag on submit card payment.

If set to true the card payment gateway will be directed to proceed with a payment even if the address verification checks fails.

If set to true the card payment gateway will be directed to proceed with a payment even if the card verification number check fails.

Optional field that if specified indicates the processor merchant ID that should be used to process any card payments. Mainly useful where a merchant has multiple processor merchant ID's. If left empty the default merchant card settings will be used.

If the card payment option is enabled this field indicates which card processor the merchant is set up to use.

Bitcoin Lightning invoice for the payment request.

The current status of the payment request. Will be set to FullyPaid when the full amount has been received.

This is a convenience link generated for payment requests whose merchants are using hosted payment pages. The link will load the MoneyMoov hosted payment page. If the merchant has not been set up for hosted payment or the payment can't be hosted then this property will be empty.

The approach to use, or not, for accepting partial payments.

The timestamp the payment request was created at.

The Inserted timestamp output as a sortable string https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-date-and-time-format-strings#UniversalSortable Format also supported natively by Javascript https://tc39.es/ecma262/#sec-date-time-string-format.

The timestamp the payment request was last updated at.

If set to true, and the merchant is configured for hosted payment pages, the base and callback URLs will be set to use the hosted payment page.

Optional email address for the customer. If the tokenise card option is set then the customer email address is mandatory.

If Stripe is being used as the card payment processor this property is used to hold the Stripe payment intent ID.

If Stripe is being used as the card payment processor this property is used to hold the Stripe payment intent client secret.

The jwk containing the public key used to verify the signature of the payment request.

The ID of the bank that is set as the priority bank for display on pay element.

A generic field to contain any additional data that the merchant wishes to store against the payment request. E.g. product or service information.

An optional comma separated list of partial payment amounts. The amounts represent guidance, or suggestions, as to how the payer will be requested to make partial payments.

The ID of a payrun that needs an account top up. Payment request can be used to top up payrun accounts.

Total amount received for this payment request.

Total amount refunded for this payment request.

Total amount that has been authorised but not settled for this payment request.

Description of the merchant token in case the Payment request was created using a merchant token.

Date and time of expiration of the lightning invoice.

If set to true, a receipt will be automatically sent to the CustomerEmailAddress when payments are received.

Sandbox only. Optional. If set, simulated settlements will be delayed by the specified number of seconds.

The due date for the payment request.

Optional ID of the direct debit mandate associated with this payment request.

Indicates whether the payment request is archived.