Payment initiation

Open Banking Read/Write API

UK domestic payment with detached JWS

Consent, funds check, submission. The consent and payment bodies must be byte-identical in their Initiation blocks, and both write calls carry a detached JWS.

Why read this

UK PISP work. The strictness pays off: once conformant, behaviour across banks is remarkably uniform.

Samples in this flow

Try in live showcase

pispukjwsfapifaster payments

Transaction flow

PSUUserTPPProviderASPSPBankSCAAuth01 Create the payment consent01 POST02 Authorise via OIDC with intent binding0203 Confirm funds03 GET04 Submit the payment04 POST05 Read the status05 GET
PSU: UserTPP: ProviderASPSP: BankSCA: Auth
API hop Clearing hopClick a tag on an arrow (pacs.008, …) for info, usage and sample
01

Create the payment consent

API layer

POST/domestic-payment-consents→ 201

Initiation plus a Risk block. x-jws-signature is a detached JWS over the body with b64=false and the OB claims in the header.

Headers that matter

x-fapi-interaction-idx-idempotency-keyx-jws-signature

tppaspsp

API payload· XML

UK domestic payment consent

The Initiation block here must be reproduced byte for byte in the subsequent POST /domestic-payments. The Risk block drives fraud scoring.

<payload>
<Data>
<Initiation>
<InstructionIdentification>INSTR-7F3A21</InstructionIdentification>
<EndToEndIdentification>E2E-7F3A21</EndToEndIdentification>
<InstructedAmount>
<Amount>420.50</Amount>
<Currency>GBP</Currency>
</InstructedAmount>
<CreditorAccount>
<SchemeName>UK.OBIE.SortCodeAccountNumber</SchemeName>
<Identification>40051512345678</Identification>
<Name>Thornbury Joinery Ltd</Name>
</CreditorAccount>
<RemittanceInformation>
<Reference>INV-8842</Reference>
<Unstructured>Invoice 8842</Unstructured>
</RemittanceInformation>
</Initiation>
</Data>
<Risk>
<PaymentContextCode>BillPayment</PaymentContextCode>
<MerchantCategoryCode>5211</MerchantCategoryCode>
</Risk>
</payload>
18 elementsdepth 4861 charsxml
Open sample page →See this step in live →