Creates payment requests in batch.
<b>Authorization</b>: End user or Merchant token is required.
<b>User permissions required</b>: CanCreatePaymentRequests
Request
- Base URL: https://api.nofrixion.com
- URL: https://api.nofrixion.com/api/v1/paymentrequests/batchcreate
- Auth: API key in header Authorization
Request body
The ID of the merchant to create the payment request for.
The amount of money to request.
The currency of the payment request.
An optional customer identifier for the payment request. This field is sent to the payer's bank when using payment initiation. The restriction in the available characters is due to some banks rejecting requests when ones outside the set are used.
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.
The payment methods that the payment request supports.
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.
Optionally the first name of the customer's shipping address.
Optionally the last name of the customer's shipping address.
Optionally the first line of the customer's shipping address.
Optionally the second line of the customer's shipping address.
Optionally the city of the customer's shipping address.
Optionally the state or county of the customer's shipping address.
Optionally the post code of the customer's shipping address.
Optionally the country code of the customer's shipping address.
Optionally the shipping phone number for the customer.
Optionally the shipping email address for the customer.
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. This cannot be 'None' if CardCreateToken is set to true. If this is set to 'UserConsentRequired' then, the user consent will overwrite CardCreateToken flag on submit card payment.
If set to true for card payments the sensitive card number and card verification number will be transmitted directly rather than being tokenised. This makes the payment quicker but more exposed to client side flaws such as cross site scripting.
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 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.
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.
If set to true for card payments no attempt will be made to use payer authentication (3-D Secure and equivalent). Skipping payer authentication can help avoid failed payment attempts when a payer is not enrolled or when they can't be bothered completing their issuing bank's authentication steps. A disadvantage is it exposes the merchant to liability for charge backs.
The approach to use, or not, for accepting partial payments.
Optional email address for the customer. If the tokenise card option is set then the customer email address is mandatory.
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.
Optional, if set it indicates that this payment request will be used to top up a payment account for a pay run.
Sandbox only. Optional. If set, the simulated Direct Debit settlement will be delayed by the specified number of seconds. Must be greater than 0 and less than 600. Otherwise, the default value will be used.
An optional list of tag ids to add to the payment request
An optional list of tag values to set on the payment request. If no matching tag exists it will be created.
If set to true, a receipt will be automatically sent to the CustomerEmailAddress when payments are received.
An optional due date for the payment request.
An optional list of notification role IDs that will receive notifications about the payment request. This is useful for roles that need to be notified about payment request events.
Optional ID of an existing direct debit mandate to associate with this payment request. Only applicable when the payment method is direct debit.
Response
A PaymentRequestsCreateResponse.
Changes
No recorded changes to this endpoint across all 2 revisions of this API.