Immediate Payment Requests (BETA)

Create a payment request for immediate transfer execution.

Immediate payment requests are executed via Masav's "Request-To-Pay" rails, that enables immediate payment execution upon approval.

📘

Supported Banks

  • Leumi - 10
  • Poalim - 12
  • Discount /Mercantile- 11,17
  • Mizrahi - 20
  • FIBI group - 14,26,31,46,52

Prerequisites

  • Feezback must approve your onboarding before you can start.
    Contact your Feezback integration contact to enable immediate payment requests on your account.
  • The onboarding process includes registering for a Masav account and approval from the creditor account bank.
  • We will guide you on how to initiate and complete the process.
  • Amount limitations may apply according to your bank account permissions (may be negotiable with your bank account manager)

How it works?

  1. You call Feezback's API with the payment request details
  2. The payment request is delivered to Masav and waits for the debtor inside their own bank's digital channels (app/website).
  3. The debtor logs in to their bank independently and approves the request there.
    Once approved, the transfer is executed immediately and finally — RTP payments cannot be cancelled or reversed once accepted.

Available on both the Feezback link and Seamless flows

If you already integrate with Feezback's payment links service, immediate payment requests uses the same integration, the same JWT/Seamless request shape, and the same webhook — you opt in with a single new parameter, paymentMethod.

When to use which?

  • If you don't have the full debtor ID and account number - use Feezback link: you will receive a link where the debtor can enter their details and the request will await at their bank account
  • If you have all the debtor details: use the seamless flow and the request will await directly at the debtor's bank portal.

Requesting an Immediate Payment

The request is using the parameter paymentMethod, added to the same request you already use for Payment Links.

ParameterRequiredValuesDefault
paymentMethodNo"RTP" | "PIS""PIS"

If you omit paymentMethod entirely, your integration behaves exactly as it does today (a standard payment link).

Feezback Link Flow

Add paymentMethod: "RTP" at the same level as your other flow fields when creating the link, exactly as documented for standard FAST payments.

{
  "encrypt": true,
  "iss": "tpp/sandbox",
  "srv": "fast/user",
  "sub": "user-123",
  "flow": {
    "id": "default",
    "userWasAuthenticated": false,
    "context": "tx-20260113001",
    "paymentMethod": "RTP",
    "userIdentifier": { "type": "ID", "value": "000000000", "editable": true },
    "redirects": {
      "pisSuccess": "https://example.com/success",
      "pisFailure": "https://example.com/failure",
      "pisNotComplete": "https://example.com/notcomplete",
      "ttlExpired": "https://example.com/expired"
    },
    "payment": {
      "remittanceInformationUnstructured": "Payment to Company Ltd",
      "creditor": {
        "name": "Company Ltd",
        "account": "IL12342170000000061234",
        "accountType": "iban"
      },
      "transfer": {
        "amount": { "value": "1.00", "editable": true },
        "currency": { "value": "ILS", "editable": false }
      }
    }
  }
}
curl --location --request POST \
  'https://{ENVIRONMENT}.feezback.cloud/link' \
  --header 'Content-Type: application/json' \
  --data-raw '{"token": "{GENERATED_JWT_TOKEN}"}'

The response contains a link, exactly as for a standard payment link.
Send this link to your debtor.

All other JWT fields, validation rules, and error codes are identical to standard payment. paymentMethod is the only addition.

Seamless Flow

Add paymentMethod: "RTP" to the request body sent to the Payments API, alongside your existing Seamless fields.

{
  "idValue": "200200202",
  "accountType": "private",
  "paymentMethod": "RTP",
  "creditorAccount": "IL760125380000000693304",
  "creditorName": "Recipient Ltd",
  "remittanceInformationUnstructured": "Payment reason",
  "bankCode": "10",
  "amount": "1.00",
  "context": "unique-tx-id",
  "userAgreementTimestamp": "2026-03-18T12:09:05+00:00",
  "redirectSuccess": "https://example.com/success",
  "redirectFailure": "https://example.com/failure",
  "redirectNotComplete": "https://example.com/notComplete",
  "redirectNotConclusive": "https://example.com/notConclusive"
}
curl --location --request POST \
  'https://{ENVIRONMENT}.feezback.cloud/tpp/v1/users/{SUB}@{TPP_ID}/payments' \
  --header 'Authorization: Bearer {TOKEN}' \
  --header 'Content-Type: application/json' \
  --data '{...}'

In response you will get a link with instructions for the debtor. You don't have to use it as the debtor will receive an SMS message from their bank and the request will await them at the bank portal.


How the RTP Flow Differs From FAST/PIS

RTP reuses the FAST/Seamless screens and logic, with these differences:

AreaFAST/PISRTP
CompletionUser redirected to the bank to finish the paymentNo redirect — the request waits for the user inside their own bank app/site
Desktop intro screenShownNot shown
Terms & ConditionsStandard T&CRTP-specific T&C text per TPP (if you offer both PIS and RTP, each shows its own T&C)
FinalityCan be rejected/adjusted through the normal PIS flowAlways immediate and final once accepted — no partial approval, no cancellation (see §7 Roadmap)
End screen (LGS flow)Redirect to your success/failure URLFeezback shows an interim "Payment Pending" screen while waiting for the debtor to act in their bank (LGS flow only)

Errors

If the RTP message cannot be delivered to Masav (no response, or an error response to the request), the user sees a generic error message and can retry, up to a limit of 3 attempts before a short cooldown is applied. If this happens repeatedly or you cannot resolve it, contact Feezback support with the context value and timestamp.


Webhooks

RTP payments use the same webhook event as payment links: PaymentStatusChanged, with the same payload shape you already receive for payment links. Two things change for RTP:

  • The payload includes a payment_method field with the value "RTP" or "PIS", so you can tell which payment method a given webhook relates to.
  • transferType is reported as "fp", reflecting that RTP transfers are immediate and non-cancellable.

RTP Payment Statuses

StatusMeaning
receivedThe RTP message was accepted by Masav (equivalent to getting a 201 response and no immediate cancellation signal). Shown while the debtor has not yet acted.
rejectedThe bank declined the request — either immediately (cancellation signal from Masav) or after the debtor's bank explicitly rejected it, or the debtor rejected it in their own bank app.
acceptedSettlementCompletedThe transfer was completed — this is the final success status.
expiredThe debtor did not respond by the expiration date set in the original request.

As with any webhook, do not assume the payload is limited to the fields documented here — the bank may include additional fields.



Testing

RTP can be tested on lower environments before going live:

  • Use your integration environment as you do today for single payments.
  • New integrations will test against the Masav test/simulator environment before moving to production.


Did this page help you?