TPP · Banking · Service Initiation · Delegated SCA

Delegated SCA — API Guide 4 min read

A Delegated SCA consent authorises a TPP to initiate multiple payments at variable amounts over the lifetime of the consent. The user authorises the consent once. Unlike other multi-payments a Delegated SCA consent does not contain predefined control parameters. Instead, the TPP is responsible for performing Strong Customer Authentication (SCA) on the user before each payment request (POST /payments).

Common use cases include digital wallet experiences where the TPP authenticates the user within its own app, as well as usage-based services such as taxi rides, EV charging sessions, and other metered services where the final charge is presented to the user after the service is completed.

01 Prerequisites

What you need before initiating a Delegated SCA payment

Before initiating a Delegated SCA payment, ensure the following requirements are met:

  • Registered Application — the application must be created within the Trust Framework and assigned the BSIP role as defined in Roles.
  • Valid Transport Certificate — an active transport certificate must be issued and registered in the Trust Framework to establish secure mTLS communication.
  • Valid Signing Certificate — an active signing certificate must be issued and registered in the Trust Framework. This certificate is used to sign request objects and client assertions.
  • Registration with the relevant API Hub (Authorisation Server) — the application must be registered with the API Hub (Server) of the LFI with which you intend to initiate payments.
  • Understanding of the FAPI Security Profile and Tokens & Assertions — you should understand how request object signing, client authentication, and access token validation underpin secure API interactions.
  • Understanding of Message Encryption — PII (creditor name and account details) must be encrypted as a JWE before being embedded in the consent. You will need the LFI's public encryption key from their JWKS.
02 API Sequence Flow

End-to-end Delegated SCA

Sequence diagramDelegated SCA API FlowClick to expand
03 POST /par · Step 1 — Encrypting PII

Sign and encrypt the consent PII

POST/par

The consent.PersonalIdentifiableInformation property in the authorization_details carries sensitive payment data — creditor account details, debtor information, and risk indicators. Because consents are stored centrally at Nebras, this data is encrypted end-to-end so that no intermediate party can read it.

The schema defines PersonalIdentifiableInformation as a oneOf with three variants:

VariantFormNotes
Domestic Payment PII Schema ObjectobjectUnencrypted form — shows the PII structure for domestic payments. For reference only.
International Payment PII Schema ObjectobjectUnencrypted form — shows the PII structure for international payments. For reference only.
Encrypted PII Object (AEJWEPaymentPII)stringCompact JWE string. MUST be used when invoking the PAR operation.
Domestic Payment PII Schema Object must be strictly followed

The object you encrypt MUST conform exactly to the Domestic Payment PII Schema Object. Field names, nesting, and data types are validated by the LFI after decryption — any deviation will result in payment rejection. Do not add undocumented fields or omit required ones.

See Personal Identifiable Information for the complete field reference, required vs optional fields, and creditor models for each domestic payment type.

Creditor array — choosing a beneficiary model

Initiation.Creditor determines the beneficiary model for all payments made under this consent:

EntriesModelEffect
OmittedOpen beneficiaryNo creditor fixed at consent time — each POST /payments supplies its own creditor
1 entrySingle beneficiaryConsent is bound to that one recipient — every payment must go to that account
2–10 entriesMultiple beneficiariesConsent authorises any one of the listed accounts — each payment specifies which one

See Creditor for the field schema, matching rules, and validation requirements.

The PII object is serialized to JSON, signed as a JWS using your signing key, and then encrypted as a JWE using the LFI's public encryption key — producing the AEJWEPaymentPII compact string embedded as PersonalIdentifiableInformation in the consent.

Encrypting the PII

Build the PII object according to the schema, then encrypt it as a JWE using the LFI's public encryption key:

typescript
import { SignJWT, importJWK, CompactEncrypt } from 'jose'

/**
 * Sign PII as a JWT and encrypt it as a JWE using the LFI's public encryption key.
 * Fetch the LFI's JWKS URI from their .well-known/openid-configuration.
 */
async function encryptPII(pii: object, jwksUri: string, signingKey: CryptoKey, signingKeyId: string): Promise<string> {
  // 1. Sign the PII as a JWT
  const signedPII = await new SignJWT(pii as Record<string, unknown>)
    .setProtectedHeader({ alg: 'PS256', kid: signingKeyId })
    .sign(signingKey)

  // 2. Fetch the LFI's encryption key
  const { keys } = await fetch(jwksUri).then(r => r.json())
  const encKeyJwk = keys.find((k: { use: string }) => k.use === 'enc')
  if (!encKeyJwk) throw new Error('No encryption key (use: enc) found in JWKS')

  const encKey = await importJWK(encKeyJwk, 'RSA-OAEP-256')

  // 3. Encrypt the signed JWT
  return new CompactEncrypt(new TextEncoder().encode(signedPII))
    .setProtectedHeader({
      alg: 'RSA-OAEP-256',
      enc: 'A256GCM',
      kid: encKeyJwk.kid,
    })
    .encrypt(encKey)
}

const pii = {
   "Initiation": {
     "DebtorAccount": {
       "SchemeName": "IBAN",
       "Identification": "AE070331234567890123456",
       "Name": {
         "en": "Mohammed Al Rashidi",
       }
     },
    // Creditor array is optional — omit for open beneficiary, or supply 1–10 entries
    "Creditor": [
      {
        "Creditor": {
          "Name": "Ivan England"
        },
        "CreditorAccount": {
          "SchemeName": "IBAN",
          "Identification": "AE070331234567890123456",
          "Name": {
            "en": "Ivan David England"
          }
        }
      }
    ]
  }
}

const encryptedPII = await encryptPII(pii, LFI_JWKS_URI, signingKey, SIGNING_KEY_ID)
// encryptedPII is a compact JWE string — embed it in authorization_details below

See Message Encryption for details on fetching the LFI's JWKS and selecting the correct encryption key.

Delegated SCA requires a populated Risk block

Unlike standard payment flows, Delegated SCA MUST prove the SCA already performed at the TPP. At minimum, Risk.DebtorIndicators.Authentication must demonstrate MFA with two distinct factors, and the wider Risk block must be fully populated with everything derivable from your system.

Risk blockjsonc
{
  "Risk": {
    "DebtorIndicators": {
      "Authentication": {
        "AuthenticationChannel": "App",
        "AuthenticationFlow":    "MFA",
        "ChallengeOutcome":      "Pass",
        "ChallengeDateTime":     "2025-06-19T09:55:44Z",
        "PossessionFactor": { "IsUsed": true, "Type": "SecureEnclaveKey" },
        "InherenceFactor":  { "IsUsed": true, "Type": "Fingerprint" }
      },
      "GeoLocation":       { "Latitude": "25.1972", "Longitude": "55.2744" },
      "DeviceInformation": { "DeviceType": "Mobile" /* ... */ }
      // AppInformation, BiometricCapabilities, AccountRiskIndicators, ...
    },
    "TransactionIndicators": {
      "IsCustomerPresent": true,
      "Channel":           "Mobile",
      "ChannelType":       "InApp"
      // SubChannelType, PaymentProcess, ...
    },
    "CreditorIndicators": {
      "AccountType":         "Retail",
      "IsCreditorConfirmed": true
      // IsCreditorPrePopulated, IsVerifiedByTPP, ...
    }
  }
}

See the Delegated SCA Payment example for a fully-populated version and the Risk reference for the field-by-field schema.

04 POST /par · Step 2 — Constructing Authorization Details

Build the consent payload

With the encrypted PII ready, construct the authorization_details of type urn:openfinanceuae:service-initiation-consent:v2.1. For Delegated SCA you must set ControlParameters.IsDelegatedAuthentication to true and leave ConsentSchedule empty, indicating that the TPP will perform SCA on the user before each POST/payments request.

authorization_details

FieldTypeDescriptionExample
type*enumMust be urn:openfinanceuae:service-initiation-consent:v2.1urn:openfinanceuae:service-initiation-consent:v2.1
consent*objectConsent properties agreed by the User with the TPP. Described below.
subscriptionobjectOptional subscription to Event Notifications via Webhook. Described below.

consent (Required) | authorization_details.consent

FieldTypeDescriptionExample
ConsentId*string (uuid)Unique ID assigned by the TPP (1–128 chars)b8f42378-10ac-46a1-8d20-4e020484216d
IsSingleAuthorization*booleanWhether the payment requires only one authorizing partytrue
ExpirationDateTime*date-timeConsent expiry (ISO 8601 with timezone, max 1 year)2027-03-02T00:00:00+00:00
AuthorizationExpirationDateTimedate-timeDeadline by which all authorizers must have acted (multi-authorization only). SHOULD be set when IsSingleAuthorization is false; SHOULD NOT be set when IsSingleAuthorization is true. MUST NOT be after ExpirationDateTime.2026-03-03T10:00:00+00:00
BaseConsentIdstring (uuid)Links to prior consent if renewing — see Base Consent ID
Permissionsarray<enum>Optional access permissions granted alongside the payment consentReadAccountsBasic, ReadBalances
ControlParameters*objectMust include IsDelegatedAuthentication: true and an empty ConsentSchedule
PersonalIdentifiableInformation*string (JWE)Encrypted creditor and risk data — the encryptedPII string from Step 1eyJhbGci...
PaymentPurposeCode*string (3 chars)AANI payment purpose codeACM
DebtorReferencestringReference shown on the debtor's statementSubscription
CreditorReferencestringReference shown on the creditor's statementSubscription

ControlParameters — Delegated SCA

For Delegated SCA consents, the LFI defers payment-level controls to the TPP. Declare delegation and keep the schedule empty:

FieldRequiredDescriptionExample
IsDelegatedAuthenticationYesMust be true to indicate the TPP will perform SCA before every payment requesttrue
ConsentScheduleYesLeave empty {} — no bank-enforced caps or schedules are defined on the consent{}
Who enforces limits?

Any spend, frequency are enforced by the TPP and Strong Customer Authentication must be done before each Payment.

Example request

authorization_detailsjson
"authorization_details": [
  {
    "type": "urn:openfinanceuae:service-initiation-consent:v2.1",
    "consent": {
      "ConsentId": "{{unique-guid}}",
      "IsSingleAuthorization": true,
      "ExpirationDateTime": "2027-03-02T00:00:00+00:00",

      // Multi-authorization only: deadline for all authorizers to act.
      // SHOULD NOT be set when IsSingleAuthorization is true.
      // "AuthorizationExpirationDateTime": "2026-03-03T10:00:00+00:00",

      "Permissions": [
        "ReadAccountsBasic",
        "ReadAccountsDetail",
        "ReadBalances"
      ],

      "ControlParameters": {
        "IsDelegatedAuthentication": true,
        "ConsentSchedule": {}
      },

      // Encrypted PII from Step 1
      "PersonalIdentifiableInformation": "{{encryptedPII}}",

      "PaymentPurposeCode": "ACM",
      "DebtorReference": "Subscription",
      "CreditorReference": "Subscription"
    }
  }
]
05 POST /par · Step 3 — Constructing the Request JWT

Bind PKCE and authorization details into a signed JWT

With your authorization_details ready, generate a PKCE code pair then use the buildRequestJWT() helper, passing payments openid as the scope.

Scope change required when using Permissions

If your consent includes ReadAccountsBasic, ReadAccountsDetail, or ReadBalances, you must change the scope to accounts payments openid. Without the accounts scope the issued token will not grant access to the account endpoints. You will also need the BDSP role. See Account Permissions in a Payment Consent.

typescript
import crypto from 'node:crypto'
import { generateCodeVerifier, deriveCodeChallenge } from './pkce'
import { buildRequestJWT } from './request-jwt'

const codeVerifier  = generateCodeVerifier()
const codeChallenge = deriveCodeChallenge(codeVerifier)

const authorizationDetails = [
  {
    type: 'urn:openfinanceuae:service-initiation-consent:v2.1',
    consent: {
      ConsentId: crypto.randomUUID(),
      IsSingleAuthorization: true,
      ExpirationDateTime: new Date(Date.now() + 364 * 24 * 60 * 60 * 1000).toISOString(),
      Permissions: ['ReadAccountsBasic', 'ReadAccountsDetail', 'ReadBalances'],
      ControlParameters: {
        IsDelegatedAuthentication: true,
        ConsentSchedule: {},
      },
      PersonalIdentifiableInformation: encryptedPII,  // from Step 1
      PaymentPurposeCode: 'ACM',
      DebtorReference: 'Subscription',
      CreditorReference: 'Subscription',
    },
  },
]

const requestJWT = await buildRequestJWT({
  scope: 'payments openid',
  codeChallenge,
  authorizationDetails,
})
Store the code_verifier

Save codeVerifier in your server-side session or an httpOnly cookie — you will need it in Step 8 to exchange the authorization code for tokens.

See Preparing the Request JWT for the full JWT claim reference and PKCE helpers.

06 POST /par · Step 4 — Creating a Client Assertion

Prove the application's identity to the API Hub

Use the signJWT() helper to build a client assertion proving your application's identity:

typescript
import crypto from 'node:crypto'
import { signJWT } from './sign-jwt'

const CLIENT_ID = process.env.CLIENT_ID!
const ISSUER    = process.env.AUTHORIZATION_SERVER_ISSUER!

async function buildClientAssertion(): Promise<string> {
  return signJWT({
    iss: CLIENT_ID,
    sub: CLIENT_ID,
    aud: ISSUER,
    jti: crypto.randomUUID(),
  })
}

See Client Assertion for the full claims reference.

07 POST /par · Step 5 — Sending the /par Request

Push the request to the API Hub

Include x-fapi-interaction-id on the request — the API Hub echoes it in the response for end-to-end traceability. See Request Headers.

typescript
import crypto from 'node:crypto'

// PAR endpoint is read from .well-known/openid-configuration —
// not constructed from the issuer URL (it lives on a different host).
const PAR_ENDPOINT = discoveryDoc.pushed_authorization_request_endpoint

const parResponse = await fetch(PAR_ENDPOINT, {
  method: 'POST',
  headers: {
    'Content-Type':          'application/x-www-form-urlencoded',
    'x-fapi-interaction-id': crypto.randomUUID(),
  },
  body: new URLSearchParams({
    request:               requestJWT,
    client_assertion_type: 'urn:ietf:params:oauth:client-assertion-type:jwt-bearer',
    client_assertion:      await buildClientAssertion(),
  }),
  // agent: new https.Agent({ cert: transportCert, key: transportKey }),
})

const { request_uri, expires_in } = await parResponse.json()
mTLS transport certificate

You must present your transport certificate on every connection to the API Hub and resource APIs. See Certificates.

FieldDescriptionExample
request_uriSingle-use reference to your pushed authorization requesturn:ietf:params:oauth:request-uri:bwc4JDpSd7
expires_inSeconds until the request_uri expires — redirect the user before this window closes90
08 Redirecting the User · Step 6 — Building the Authorization URL

Send the user to the LFI to authenticate

The authorization_endpoint is found in the LFI's .well-known/openid-configuration — not constructed from the issuer URL directly.

typescript
// authorization_endpoint from .well-known/openid-configuration
// Each LFI sets its own path — there is no fixed structure
// e.g. on the altareq1 sandbox: 'https://auth1.altareq1.sandbox.apihub.openfinance.ae/auth'
const AUTHORIZATION_ENDPOINT = discoveryDoc.authorization_endpoint

const authCodeUrl = `${AUTHORIZATION_ENDPOINT}?client_id=${CLIENT_ID}&response_type=code&scope=openid&request_uri=${encodeURIComponent(request_uri)}`

window.location.href = authCodeUrl
// or server-side: res.redirect(authCodeUrl)

After redirecting, the user will see the bank's authorization screen showing:

  • The TPP name and purpose.
  • That payments will be authenticated by the TPP (Delegated SCA).
  • The consent expiry date.
User Experience

See User Experience for screen mockups of the Delegated SCA Consent and Authorization pages the user sees at the bank.

09 Handling the Callback · Step 7 — Extracting the Authorization Code

Validate state and issuer on the redirect

After the user approves, the bank redirects to your redirect_uri:

callback URL
https://yourapp.com/callback?code=fbe03604-baf2-4220-b7dd-05b14de19e5c&state=d2fe5e2c-77cd-4788-b0ef-7cf0fc8a3e54&iss=https://auth1.altareq1.sandbox.apihub.openfinance.ae
typescript
const params = new URLSearchParams(window.location.search)

const code  = params.get('code')!
const state = params.get('state')!
const iss   = params.get('iss')!

if (state !== storedState) throw new Error('State mismatch — possible CSRF attack')
if (iss !== ISSUER)        throw new Error(`Unexpected issuer: ${iss}`)

See Handling Authorization Callbacks for a full guide on state validation, issuer verification, and replay prevention.

10 Exchanging the Code for Tokens · Step 8 — POST /token (Authorization Code)

Swap the auth code for an access and refresh token

POST/token
typescript
// Token endpoint is read from .well-known/openid-configuration —
// not constructed from the issuer URL (it lives on a different host).
const TOKEN_ENDPOINT = discoveryDoc.token_endpoint

const tokenResponse = await fetch(TOKEN_ENDPOINT, {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type:            'authorization_code',
    code,
    redirect_uri:          REDIRECT_URI,
    code_verifier:         codeVerifier,            // from Step 3
    client_assertion_type: 'urn:ietf:params:oauth:client-assertion-type:jwt-bearer',
    client_assertion:      await buildClientAssertion(),
  }),
  // agent: new https.Agent({ cert: transportCert, key: transportKey }),
})

const { access_token, refresh_token, expires_in } = await tokenResponse.json()
Token storage

Never store tokens in localStorage. Use httpOnly cookies or a server-side session store. See Tokens & Assertions for the full token lifecycle.

11 Initiating Payments On-Demand · Encrypt PII for Payment Initiation

Re-encrypt the creditor PII for each payment

Each POST /payments request carries its own PersonalIdentifiableInformation — a fresh JWE encrypted for that specific payment. This follows the same JWS-inside-JWE pattern used in Step 1, but uses the Domestic Payment PII Schema Object (AEBankServiceInitiation.AEDomesticPaymentPIIProperties) rather than the consent PII schema. The creditor fields are flat on Initiation at this stage — they are not wrapped in an array.

The schema defines PersonalIdentifiableInformation for POST /payments as a oneOf with two variants:

VariantFormNotes
Domestic Payment PII Schema Object (AEDomesticPaymentPIIProperties)objectUnencrypted form — shows the payment PII structure. For reference only.
Encrypted PII Object (AEJWEPaymentPII)stringCompact JWE string. MUST be used when invoking POST /payments.
Domestic Payment PII Schema Object must be strictly followed

The object you encrypt MUST conform exactly to AEDomesticPaymentPIIProperties. Field names, nesting, and data types are validated by the LFI after decryption — any deviation will result in payment rejection. Do not add undocumented fields or omit required ones.

See Personal Identifiable Information for the complete field reference, required vs optional fields, and creditor models for each domestic payment type.

Creditor must match the consent beneficiary model

The creditor supplied here must correspond to the beneficiary model set at consent time:

  • Single beneficiary (Initiation.Creditor[] had 1 entry): CreditorAccount.SchemeName, CreditorAccount.Identification, and CreditorAccount.Name must exactly match that entry. The LFI decrypts both PII tokens and compares them; any discrepancy results in rejection.
  • Multiple beneficiaries (2–10 entries): must exactly match one entry from the pre-approved list in the consent PII.
  • Open beneficiary (Initiation.Creditor[] omitted at consent): no consent-time match required — supply any valid creditor.

See Creditor for the full matching rules and field validation requirements.

Risk block is flexible per payment

Unlike the Creditor, the Risk block does not need to match the consent PII exactly. It should reflect the actual risk context of the individual payment — for example, a different Channel or updated TransactionIndicators for each payment under the consent.

Build the PII object according to the schema, then encrypt it using the same encryptPII helper from Step 1:

typescript
const paymentPii = {
  Initiation: {
    Creditor: [
      {
        Creditor: {
          Name: 'Ivan England',                  // must match consent PII (single/multiple beneficiary)
        },
        CreditorAccount: {
          SchemeName:     'IBAN',                // must match consent PII (single/multiple beneficiary)
          Identification: 'AE070331234567890123456',  // must match consent PII (single/multiple beneficiary)
          Name: {
            en: 'Ivan David England',            // must match consent PII (single/multiple beneficiary)
          },
        },
      },
    ],
  },
  // Risk can reflect the context of this specific payment
  Risk: {
    PaymentContextCode: 'BillPayment',
  },
}

const paymentEncryptedPII = await encryptPII(paymentPii, LFI_JWKS_URI, signingKey, SIGNING_KEY_ID)
// paymentEncryptedPII is a compact JWE string — embed it in the payment request below

See Personal Identifiable Information for the complete field reference, required vs optional fields, and creditor models for each domestic payment type.

See Message Encryption for details on fetching the LFI's JWKS and selecting the correct encryption key.

12 Initiating Payments On-Demand · Step 9 — POST /payments

Submit each payment after performing SCA on the user

POST/payments

Include x-fapi-interaction-id and x-idempotency-key. As the customer must always have been present and authenticated for the TPP to instruct a delegated SCA payment, also send x-fapi-customer-ip-address, x-customer-user-agent and x-fapi-auth-date. See Request Headers.

Unlike Single Instant Payment, this step can be called multiple times under the same consent. Each call specifies the actual amount for that payment. There are no consent-time caps — make sure you have just performed SCA on the user in your own channel before sending the payment request.

Fields that can vary per payment

Unlike Single Instant Payment, multi-payment consents do not require PaymentPurposeCode, DebtorReference, CreditorReference, or OpenFinanceBilling to match the consent exactly. Only ConsentId must match the authorized consent. Instruction.Amount must be within the parameters the consent allows for this payment type.

typescript
import { SignJWT } from 'jose'

const LFI_API_BASE = process.env.LFI_API_BASE_URL!

async function initiateVariablePayment(
  accessToken: string,
  consentId: string,
  amount: string,        // amount the user just approved via your SCA flow
  paymentEncryptedPII: string,  // from the PII step above
  idempotencyKey: string,
) {
  // Wrapped in `message` per AEPaymentRequestSigned
  const paymentPayload = {
    message: {
      Data: {
        ConsentId: consentId,                    // must match the authorized consent
        Instruction: {
          Amount: {
            Amount:   amount,                  // must be within consent parameters
            Currency: 'AED',
          },
        },
        PersonalIdentifiableInformation: paymentEncryptedPII,
        PaymentPurposeCode: 'ACM',
        DebtorReference:    'Subscription',
        CreditorReference:  'Subscription',
        OpenFinanceBilling: {
          Type: 'PushP2P',
        },
      },
    },
  }

  // AUTHORIZATION_SERVER_ISSUER is the `issuer` value from the LFI's .well-known/openid-configuration
  const signedPayment = await new SignJWT(paymentPayload)
    .setProtectedHeader({ alg: 'PS256', kid: SIGNING_KEY_ID, typ: 'JWT' })
    .setIssuedAt()
    .setIssuer(CLIENT_ID)
    .setAudience(AUTHORIZATION_SERVER_ISSUER)
    .setExpirationTime('5m')
    .sign(signingKey)

  const paymentResponse = await fetch(`${LFI_API_BASE}/open-finance/payment/v2.1/payments`, {
    method: 'POST',
    headers: {
      Authorization:                `Bearer ${accessToken}`,
      'Content-Type':               'application/jwt',
      'x-idempotency-key':          idempotencyKey,
      'x-fapi-interaction-id':      crypto.randomUUID(),
      'x-fapi-auth-date':           lastCustomerAuthDate,
      'x-fapi-customer-ip-address': customerIpAddress,
    },
    body: signedPayment,
    // agent: new https.Agent({ cert: transportCert, key: transportKey }),
  })

  const { Data: { PaymentId, Status } } = await paymentResponse.json()
  return { PaymentId, Status }
}

// First payment
const { PaymentId: pay1 } = await initiateVariablePayment(access_token, consentId, '149.99', paymentEncryptedPII, crypto.randomUUID())

// Second payment (days/weeks later using a refreshed access token)
const { PaymentId: pay2 } = await initiateVariablePayment(refreshedToken, consentId, '89.00', paymentEncryptedPII, crypto.randomUUID())
13 Token refresh for subsequent payments

Use the refresh_token to keep the session alive

The initial access token expires after 10 minutes. For subsequent on-demand payments, use the refresh_token to obtain a new access token without re-involving the user:

typescript
// Token endpoint is read from .well-known/openid-configuration —
// not constructed from the issuer URL (it lives on a different host).
const TOKEN_ENDPOINT = discoveryDoc.token_endpoint

const refreshResponse = await fetch(TOKEN_ENDPOINT, {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type:            'refresh_token',
    refresh_token:         storedRefreshToken,
    client_assertion_type: 'urn:ietf:params:oauth:client-assertion-type:jwt-bearer',
    client_assertion:      await buildClientAssertion(),
  }),
  // agent: new https.Agent({ cert: transportCert, key: transportKey }),
})

const { access_token: newToken, refresh_token: newRefresh } = await refreshResponse.json()
// Update your stored tokens

See Tokens & Assertions for refresh token lifetimes and rotation policy.

14 A successful POST /payments

201 Created — signed JWT response

A 201 Created response is returned as a signed JWT (application/jwt). Verify the signature using the LFI's public signing key before reading the payload.

Response headers

HeaderDescription
LocationURL of the created payment resource — /open-finance/payment/v2.1/payments/{PaymentId}
x-fapi-interaction-idEcho of the interaction ID from the request
x-idempotency-keyEcho of the idempotency key from the request

Response body — Data

FieldRequiredDescription
PaymentIdYesLFI-assigned unique identifier for this payment resource (use this to poll for status)
ConsentIdYesThe consent this payment is bound to
StatusYesCurrent payment status — see status lifecycle below
StatusUpdateDateTimeYesISO 8601 datetime of the last status change
CreationDateTimeYesISO 8601 datetime when the payment resource was created
Instruction.AmountYesEchoes back the amount and currency from the request
PaymentPurposeCodeYesEchoes back the payment purpose code
OpenFinanceBillingYesEchoes back the billing parameters
PaymentTransactionIdNoEnd-to-end transaction ID generated by the Aani payment rails once the payment is submitted for settlement. Not present at Pending.
DebtorReferenceNoEchoes back the debtor reference if provided
RejectReasonCodeNoArray of { Code, Message } objects — present only when Status is Rejected

Status lifecycle

StatusDescription
PendingThe payment has been accepted by the LFI and queued for processing. This is the typical status immediately after creation.
AcceptedSettlementCompletedThe debtor's account has been debited.
AcceptedWithoutPostingThe receiving LFI has accepted the payment but has not yet credited the creditor account.
AcceptedCreditSettlementCompletedThe creditor account has been credited. Payment is fully settled.
RejectedThe payment was rejected. Inspect RejectReasonCode for the reason.

Links

FieldDescription
SelfURL to this payment resource — use for status polling
RelatedURL to the associated consent — /open-finance/v2.1/payment-consents/{ConsentId}

Example response payload

The payload is the verified body of the signed JWT. Per AEPaymentIdResponseSigned, Data and Links are wrapped in a message envelope.

201 Created — decoded JWT bodyjson
{
  "message": {
    "Data": {
      "PaymentId": "83b47199-90c2-4c05-9ef1-aeae68b0fc7c",
      "ConsentId": "b8f42378-10ac-46a1-8d20-4e020484216d",
      "Status": "Pending",
      "StatusUpdateDateTime": "2026-05-03T15:46:01+00:00",
      "CreationDateTime": "2026-05-03T15:46:01+00:00",
      "Instruction": {
        "Amount": {
          "Amount": "100.00",
          "Currency": "AED"
        }
      },
      "PaymentPurposeCode": "ACM",
      "DebtorReference": "Invoice 1234",
      "OpenFinanceBilling": {
        "Type": "PushP2P"
      }
    },
    "Links": {
      "Self": "https://api.lfi.example/open-finance/payment/v2.1/payments/83b47199-90c2-4c05-9ef1-aeae68b0fc7c",
      "Related": "https://api.lfi.example/open-finance/v2.1/payment-consents/b8f42378-10ac-46a1-8d20-4e020484216d"
    }
  }
}
Store the PaymentId

Persist PaymentId immediately — it is required to poll GET /payments/{PaymentId} for status updates. A payment typically moves from Pending to a terminal status within seconds, but network conditions may require polling.

See the POST /payments API reference for the full request and response schema.

Consent stays Authorized

After each successful payment, the consent remains in the Authorized state until it expires or is revoked. You do not need to re-initiate the authorization flow.