The Create Credit Transfer request requires that you have first created a beneficiary. In some scenarios it is simpler to generate both the beneficiary and the payment at the same time and this request allows you to do that.
The Idempotency check is only against successful requests, so where a previous call has resulted in any of the following HTTP Response Codes, that Idempotency key may be reused without any issue:
SEPA Credit Transfers
When creating a SEPA Credit Transfer (also referred to as an SCT or CT) payments, note that:
- Payments are processed for EUR currency payments only
- CT payments, unlike Direct Debit payments, do not require that the transaction is passed to the SEPA Clearing system days in advance of the collection date.
- If you create your CT payment early enough on a specific working day (before 8AM GMT), the funds will typically be credited to your beneficiary on the same day.
- If you create the payment later in the day then the CT will generally be credited to the beneficiary on the following business day.
The Faster Payments Scheme (FPS) is an instant payment scheme (with funds being credited to the beneficiary generally in a matter of seconds) available in the UK. Note that FPS:
- Is available for GBP curency payments only.
- Unlike SEPA CT, FPS is a 24/7/365 system.
- Requires the following values in your request:
Payments can have a
|Currency||Default Type||CT Type|
||Bacs Direct Credit|
By default EUR payments are processed as
STANDARD; GBP payments are processed as
Where you specify
FASTEST_POSSIBLE a payment will go via the the Express payment if possible (i.e. if configured for you); if it is not possible to send the payment as Express then the transaction will be processed as a Standard payment.
When working with our APIs, please use the Sandbox URI when testing and the Live URI when you move to Production.
LIVE https://api.nuapay.com SANDBOX https://sandbox.nuapay.com/
If you haven't done so already and would like to do some testing, please Request Sandbox Access
Important: Endpoints and Webhooks may be extended from time to time and any changes we make will follow our Versioning and Backward Compatibility rules. This means that the code that you write today must be designed to be robust enough to handle any future changes (where a new object is added to (or removed from) a specific API response, for example).