Payments Webhook

For general webhook mechanics (response requirements, security, IP whitelisting, troubleshooting), see Webhooks - Async Updates or Webhook Security

Event: `PaymentStatusChanged`

Fired on every status transition of a payment link/request (single/periodic/bulk)

ℹ️ Bulk Payouts fires the same event with a different payload shape (see Bulk Payouts Webhook).

ℹ️ The payload shape depends on the required payment service. Different payment services (single/periodc/bulk) or rails (payment request vs. payment links) fires the same event with different payload shape and content.

ℹ️ Do not validate against a strict schema; Since we do not filter out additional fields received by the aspsp, the payload may return additional fields that aren't listed here.

ℹ️ The Presence column below tells you whether a field is always sent for that variant ("Fixed") or only sent under certain conditions ("Optional") — check the condition before assuming a field will be there.

{
  "timestamp": "2021-03-04T12:26:32.212913+00:00",
  "event": "PaymentStatusChanged",
  "payload": { ... }
}

Single payment

The base shape for a single payment link.

Field	Type	Presence	Description	Example
`user`	String	Fixed	The user identifier you set in the JWT @ your tppId	`"123456782@tppId"`
`paymentRequest`	String	Fixed	Feezback-generated UUID for the payment request	`"9739700b-..."`
`psuId`	String	Fixed	debtor ID or passport used for bank identification.	`"123456782"`
`requestedAmount`	String	Fixed	Amount requested	`"1.00"`
`finalAmount`	Object / `false`	Fixed	Final settled amount	`{"amount": "1.00", "currency": "ILS"}`
`aspspCode`	String	Fixed	Bank code	`"20"`
`accountNumber`	String	Optional — may be missing when not requiring the account number upfront from the user.	IBAN / BBAN account number	`"IL7902..."`
`psuMessage`	String	Fixed	Reference number (אסמכתא). Mandatory for single payments. NA for periodic payments.	`"002115"`
`referenceNumber`	String	Optional	an additional reference value the bank may optionally return, which may include other bank-specific references (distinct from the regulated `psuMessage`)	`"002115"`
`context`	String	Optional — only if you sent `context` in the original request (recommended for Feezback Link, required for Seamless)	The `context` you sent in the original JWT	`"tx-001"`
`transferType`	String	Fixed	`"masav"` \| `"fp"` \| `"zahav"`
`accountType`	String	Fixed	`"PRIVATE"` \| `"BUSINESS"` \| `"CORPORATE"`
`corporateId`	Number	Optional — only for corporate accounts.	Corporate ID, if relevant	`515555555`
`paymentMethod`	String	Fixed	The paymentMethod used for the payment: 'PIS' for payment links. 'RTP' for immediate payment requests. 'OB_RTP' for open banking payment requests	`"PIS"`
`resourceId`	String	Fixed for payment link. Replaced with 'instructionId' for payment requests.	Bank-side resource identifier for the payment.
`lastStatusChange`	ISO datetime	Fixed	Timestamp of the most recent status transition
`remittanceInformation` `Unstructured`	String	Fixed	Free-text for payment description (סיבת ההעברה). You may set it in advance via the JWT.	"תשלום עבור שירות 123״
`remittanceInformation` `UnstructuredMatch`	String	Optional — only present when the creditor account is connected via the Match service	The unique value Feezback embeds inside `remittanceInformationUnstructured` so the payment can be identified on the creditor's bank statement (see the `executed` status note below).
`currentStatus`	String	Fixed	The current status of the payment. See status table below
`previousStatus`	String \| null	Fixed (nullable) — `null` if this is the first status update	The precious status of the payment.
`tpp`	String	Fixed	Your organization identifier	`"tppID"`

Periodic payment (הוראת קבע)

ℹ️ In this variant, finalAmount comes back as false (not an object) until a terminal status is reached, because the final amount of a future occurrence isn't known yet.

ℹ️ These 3 fields do not appear on the single-payment webhook at all. They appear only for periodic payment. Otherwise, it's the same shape as single payments, plus:

Field	Type	Presence	Description	Example
`recurring`	Boolean	Fixed	Always `true` in this variant	`true`
`startDate`	ISO date	Fixed	the forst execution date of the recurring schedule	`"2025-12-12"`
`occurrences`	Number	Optional	Total number of occurrences in the schedule. If not-sent, the payment has no pre-defined occurences and will continue until cancelled.	`12`

Payment Requests

Similar payload to the single payment variant, with the following additions:

Field	Type	Presence	Description
`instructionId`	String	Fixed only for open banking payment requests.	A unique identifier of the payment request generated specifically for open banking payment requests.
`executionDate`	ISO date	Optional - if set in advance.	Scheduled/actual execution date
`requestStatus`	String	Fixed	Status of the payment request itself (the pending authorization) — separate from `currentStatus`, which reflects the underlying transaction. See values below.

Not included for payment requests: requestedAmount, psuMessage, referenceNumber, context, resourceId, remittanceInformationUnstructuredMatch — they don't apply to this payload shape at all.

Why two status fields: in OB-RTP, a payment request can be waiting for authorization (tracked by requestStatus) independently of the actual transaction execution (tracked by currentStatus/previousStatus) — the two lifecycles are separate.

Statuses

Status	Definition	Masav	FP	Zahav	Comment
`received`	Payment initiation request is received by the bank.	First status	First status	First status	Triggers when the user is redirected to the bank.
`rejected`	Payment initiation has been rejected.				When we get this status, the user is redirected to Feezbacl/Your rejection url.
`expired`	The timeout for the RCVD payment has expired.				When we get this status, the user is redirected to Feezback/Your expiration url.
`partially` `Accepted` `Technical` `Correct`	The transaction requires multiple authentications, where some but not yet all have been performed.				Mostly relevant for corporate accounts where approval process required. This status means the transaction awaits further approval by other account assignees. After the transaction is approved by the rest of the assignees, the status will change to `acceptedTechnicalValidation`.
`accepted` `Funds` `Checked`	Preceding check of technical validation and customer profile was successful, and an automatic funds check was positive.	X	Last status	X
`accepted` `Technical` `Validation`	Transaction approved by the debtor bank and will be executed by the end of the current business day.	Last status	X	X	The debtor has the option to cancel the transfer on the bank channels until the transfer is executed. If approved after hours, it will be assigned to the next business day.
`accepted` `With` `Change`	Transaction approved by the debtor bank and will be executed by the end of the current business day, with minor changes like shortening the description of the transfer.	Last status	X	X	The debtor has the option to cancel the transfer on the bank channels until the transfer is executed. If approved after hours, it will be assigned to the next business day.
`accepted` `Settlement` `In` `Process`	Transaction approved by the debtor bank and will be executed immediately.	X	Last status	X
`accepted` `Settlement` `Completed`	Transfer approved and executed by the debtor bank immediately.	X	Last status	X	Settlement of the transaction has been executed and booked on the debtor account.
`accepted` `Settlement` `Completed` `Creditor` `Account`	Settlement on the creditor's account has been completed.	X	X	Last status	Settlement of the transaction has been executed and booked on the creditor account (relevant only for Zahav payments).
`executed`	Funds received in the creditor account.	Last status	Last status	Last status	Relevant for the "Match" service. For customers that enabled tracking transactions in the creditor account, this will always be the last status, overriding other final statuses.
`cancelled`	The user cancelled the payment.	Last status	X	X	For periodic payments only. Will be received if the user cancelled the periodic order via the bank channels (not supported on FIBI banks).

Common questions

Question	Answer
`previousStatus` is `null`	This is the first status update for this payment
`finalAmount: false` on a recurring payment	Normal — final amount isn't known until a terminal status
Did `acceptedTechnicalValidation` succeed?	Yes (Masav/Zahav) — will execute by end of business day
Not receiving this webhook	Check IP whitelisting — see Webhooks & IP Whitelisting

Event: PaymentStatusChanged

Single payment

user

String

Fixed

The user identifier you set in the JWT @ your tppId

paymentRequest

String

Fixed

Feezback-generated UUID for the payment request

psuId

String

Fixed

debtor ID or passport used for bank identification.

requestedAmount

String

Fixed

Amount requested

finalAmount

Object / false

Fixed

Final settled amount

aspspCode

String

Fixed

Bank code

accountNumber

String

Optional — may be missing when not requiring the account number upfront from the user.

IBAN / BBAN account number

psuMessage

String

Fixed

Reference number (אסמכתא).Mandatory for single payments. NA for periodic payments.

referenceNumber

String

Optional

an additional reference value the bank may optionally return, which may include other bank-specific references (distinct from the regulated `psuMessage`)

context

String

Optional — only if you sent context in the original request (recommended for Feezback Link, required for Seamless)

The context you sent in the original JWT

transferType

String

Fixed

"masav" | "fp" | "zahav"

accountType

String

Fixed

"PRIVATE" | "BUSINESS" | "CORPORATE"

corporateId

Number

Optional — only for corporate accounts.

Corporate ID, if relevant

paymentMethod

String

Fixed

The paymentMethod used for the payment:

'PIS' for payment links.

'RTP' for immediate payment requests.

'OB_RTP' for open banking payment requests

resourceId

String

Fixed for payment link. Replaced with 'instructionId' for payment requests.

Bank-side resource identifier for the payment.

lastStatusChange

ISO datetime

Fixed

Timestamp of the most recent status transition

remittanceInformationUnstructured

String

Fixed

Free-text for payment description (סיבת ההעברה). You may set it in advance via the JWT.

remittanceInformationUnstructuredMatch

String

Optional — only present when the creditor account is connected via the Match service

The unique value Feezback embeds inside remittanceInformationUnstructured so the payment can be identified on the creditor's bank statement (see the executed status note below).

currentStatus

String

Fixed

Event: `PaymentStatusChanged`

`user`

`paymentRequest`

`psuId`

`requestedAmount`

`finalAmount`

Object / `false`

`aspspCode`

`accountNumber`

`psuMessage`

Reference number (אסמכתא).
Mandatory for single payments. NA for periodic payments.

`referenceNumber`

`context`

Optional — only if you sent `context` in the original request (recommended for Feezback Link, required for Seamless)

The `context` you sent in the original JWT

`transferType`

`"masav"` | `"fp"` | `"zahav"`

`accountType`

`"PRIVATE"` | `"BUSINESS"` | `"CORPORATE"`

`corporateId`

`paymentMethod`

`resourceId`

`lastStatusChange`

`remittanceInformation`
`Unstructured`

`remittanceInformation`
`UnstructuredMatch`

The unique value Feezback embeds inside `remittanceInformationUnstructured` so the payment can be identified on the creditor's bank statement (see the `executed` status note below).

`currentStatus`

`previousStatus`

Fixed (nullable) — `null` if this is the first status update

`tpp`

`recurring`

Always `true` in this variant

`true`

`startDate`

`"2025-12-12"`

`occurrences`

`12`

`instructionId`

`executionDate`

`requestStatus`

Status of the payment request itself (the pending authorization) — separate from `currentStatus`, which reflects the underlying transaction. See values below.

`received`

First
status

First
status

First
status

`rejected`

`expired`

`partially`
`Accepted`
`Technical`
`Correct`

Mostly relevant for corporate accounts where approval process required. This status means the transaction awaits further approval by other account assignees. After the transaction is approved by the rest of the assignees, the status will change to `acceptedTechnicalValidation`.

`accepted`
`Funds`
`Checked`