Sending payments

This guide provides an overview of the process of sending and tracking a payment to completion, regardless of the scheme it's sent over. To learn how to submit a payment for a specific scheme, see our scheme-specific guides:

• Send a Faster Payment
• Send a book transfer

Not every scheme supports sending payments from Griffin accounts:

Scheme	Send	Receive
Faster Payments	✅	✅
Book transfers	✅	✅
Bacs Direct Credits	❌	✅
Bacs Direct Debits	❌	✅ (paying direct debits)
CHAPS	❌	✅

There are three steps to making a payment:

1. Create a payment
2. Submit the payment
3. Track the submission

there are two approaches to tracking submissions:

1. Create a webhook and listen for submission events.
2. Poll the submission resource.

Webhook based tracking

The sequence diagram below captures the payment submission lifecycle using webhooks.

caution

Webhook events may be sent out of order.

Idempotency

It's important to understand that creating a payment does not execute it, it's the submission of the payment that executes it. Payment creation is not idempotent; submission is.

If the outcome of a submission call is unknown (a timeout, or a 5xx for example), the payment may already have been submitted. Retrying the submission is safe: a duplicate submission returns 410 Gone rather than submitting the payment a second time.

If a retried submission returns 410 Gone, list the payment's submissions with GET /v0/payments/{payment-id}/submissions to determine the current state of the payment.