Charging per Mandate - חיוב לפי הרשאה

Submit direct-debit charge batches against existing mandates, then use Feezback’s a-synchronous status webhooks to track each batch through execution. This flow supports recurring billing and collections without asking the debtor to approve each individual charge.

Prerequisites

Before submitting a charge:

• Your organizationCode must be whitelisted for charging with Feezback. Contact your integration contact to confirm this is set up.
• For mandates established through Feezback, confirm that the debtor's mandate is valid through a MandateStatusChanged webhook with currentStatus: "valid" from the Direct Debit Mandate flow.
  • Store the customerId the debtor entered during Feezback mandate authorization (you receive it with the status webhook). Feezback matches this identifier to the relevant bank account number. You don't need to store the debtor bank account number as Feezback has it.
• For independently established mandates, store the debtor's account number debtorAccount and the account holder's identifier debtorPsuId

Supported mandate sources

You can charge against mandates established with Feezback or independantly:

• A mandate established through Feezback's Direct Debit Mandate flow, identified by customerId.
• A mandate established independently of Feezback, identified by debtorAccount and debtorPsuId

Environments

1. Create a token
   See Configuring Environments & Security for token issuance:

   Action	Integration URL	Production URL
   Generate a bearer token	https://lgs-integ01.feezback.cloud/token	https://lgs-prod.feezback.cloud/token

2. Send the request with the token

Method: POST · Auth: Bearer token

How it works

1. Submit a batch of charges to the endpoint above, At least 1 business day before you want to charge.
2. Feezback validates the batch and responds synchronously — this response reflects file-level and line-level validity only, not the outcome at Masav.
3. Feezback forwards valid charge lines to Masav for execution on executionDate.
4. Feezback sends a MandateBatchStatusUpdate webhook as the batch progresses through Masav.
5. Within 6 business days of executionDate, any charge line Masav rejects triggers a MandateChargeNotExecuted webhook. If no such webhook arrives for a line within that window, treat it as executed successfully.

A charge can be rejected at three points:

1. Synchronously at submission (invalid line/request).
2. Asynchronously at the file level — Masav rejects the whole batch.
3. Asynchronously at the individual charge level, up to 6 business days after executionDate (reported via MandateChargeNotExecuted). If a charge isn't rejected within that 6-day window, treat it as executed.

Submitting a charge batch

Request Configuration

{
  "context": "STRAUSS-CHG-20260716-001",
  "executionDate": "2026-07-16",
  "organizationCode": "24580",
  "charges": [
    {
      "chargeContext": "chg-00087421",
      "customerId": "8834215",
      "amount": "149.90",
      "companyName": "חברה 2",
      "remittanceInfo": "חיוב חודשי - קפסולות קפה"
    },
    {
      "chargeContext": "chg-00087422",
      "debtorAccount": "IL710110950000102188000",
      "debtorPsuId": "512222222",
      "companyName": "חברה 3",
      "amount": "89.00"
    },
    {
      "chargeContext": "chg-00087423",
      "customerId": "8834350",
      "debtorAccount": "IL710110950000102188000",
      "companyName": "חברה 4",
      "amount": "236.50"
    }
  ]
}

Identifying the debtor

Each charge line must include at least one of customerId or debtorAccount:

• Send customerId for a mandate established through Feezback. Feezback validates that the related mandate is valid and matches the relevant debtor account.
• Send debtorAccount together with debtorPsuId for a mandate established independently of Feezback. When only debtorAccount and debtorPsuId are sent (without customerId), Feezback does not perform mandate-availability validation: the line is sent to Masav as-is, and Masav rejects it if no authorization exists.
• Send both fields when you want Feezback to cross-validate them. The fields are not mutually exclusive.

debtorPsuId values

debtorPsuId identifies the holder of the debtor account , which may be a provate person or an orgzniation. Send it as a string. The value depends on who holds the account:

Example: "debtorPsuId": "512222222"

executionDate rules

• Cannot be earlier than the current date.
• Same-day execution is allowed only if the batch is submitted before 17:00 Israel time. Submissions after that cutoff for a same-day date are rejected.
• Cannot be more than 2 weeks from the current date.

Response

Feezback validates structure and per-line business rules and responds immediately — this does not wait for Masav.

There's no partial-success status, and no partial forwarding: if any charge line is invalid, the entire batch is rejected. Nothing in that batch is forwarded to Masav — errors tells you which line(s) caused the rejection so you can fix and resubmit (with a new context).

Full success:

{ "statusCode": 2000, "status": "Validated", "context": "STRAUSS-CHG-20260716-001" }

Contains invalid lines — entire batch rejected, errors identifies the offending lines:

{
  "statusCode": 2003,
  "status": "Rejected",
  "context": "STRAUSS-CHG-20260716-001",
  "errors": [
    { "chargeContext": "chg-00087422", "customerId": "8834298", "statusCode": 20032, "reason": "Mandate is not valid" },
    { "chargeContext": "chg-00087423", "customerId": "8834111", "statusCode": 20033, "reason": "customerId not found" },
    { "chargeContext": "chg-00087425", "statusCode": 20031, "reason": "Missing required field: amount" }
  ]
}

Whole-batch rejection (structural error — applies to the whole request, no specific charge line):

{
  "statusCode": 2001,
  "status": "Rejected",
  "context": "STRAUSS-CHG-20260716-001",
  "errors": [ { "reason": "organizationCode is missing from the request" } ]
}

Sub-codes returned inside errors when the top-level status is 2003:

Standard HTTP errors (401, 403, 429, 500) apply before business validation and don't carry a statusCode.

Resubmitting a batch

context must always be unique. If you submit a request with a context you've used before, it's rejected — regardless of what happened to the original batch, whether it was executed, still in progress, rejected, or never sent to Masav. There is no reuse path.

If a batch needs to be retried (for example, after fixing an invalid line), generate a new context for the retry rather than resubmitting the original.

Tracking execution

There are two webhook events for this flow. Both follow Feezback's standard envelope:

{ "timestamp": "2026-07-16T09:12:03.104Z", "event": "EventName", "payload": { ... } }

Your webhook endpoint must return HTTP 200 within 3 seconds. Don't validate against a strict schema — parse only the fields you need and ignore anything else, since fields may be added over time.

MandateBatchStatusUpdate — file-level status at Masav

{
  "timestamp": "2026-07-15T14:02:11.500Z",
  "event": "MandateBatchStatusUpdate",
  "payload": { "context": "STRAUSS-CHG-20260716-001", "status": "Sent" }
}

MandateChargeNotExecuted — per-line rejection

Fires for an individual charge line if Masav rejects it, any time up to 6 business days after executionDate. Treat a line as pending until either this webhook arrives or the 6-day window closes.

{
  "timestamp": "2026-07-18T10:41:22.019Z",
  "event": "MandateChargeNotExecuted",
  "payload": {
    "context": "STRAUSS-CHG-20260716-001",
    "chargeContext": "chg-00087423",
    "customerId": "8834350",
    "amount": "236.50",
    "executionDate": "2026-07-16",
    "reasonCode": "INSUFFICIENT_FUNDS"
  }
}

By default, only rejected lines trigger a webhook — there's no separate success notification. If you need explicit confirmation of successful charges as well, ask your integration contact; this can be enabled per account.

See reasonCode mapping here: https://docs.feezback.cloud/docs/chrage-rejection-reason-code-mapping

Charge line status reference

Note: Received describes different things at the batch level (file received by Masav) and the charge-line level (individual charge received, outcome pending) — check which object a given status appears on.

Constraints

• amount must be greater than 0, numeric, ILS only.
• organizationCode must be whitelisted for your account with Feezback.
• When sent, customerId must resolve to a mandate in valid status at time of submission — otherwise that line is rejected with 20032.
• A line with debtorAccount and debtorPsuId and no customerId is treated as an independently established mandate and does not receive mandate-availability validation.
• A line with no customerId must include both debtorAccount and debtorPsuId. If one is missing, the entire batch is rejected with 2003 and sub-code 20031.
• customerId and debtorAccount may be sent together for cross-validation.
• context must be unique — see Resubmitting a batch.
• Maximum charges per batch is not yet published — check with your integration contact if you're submitting large batches.

Coming later

• Status/query API (GET batch and per-charge status) — planned, not yet available. For now, rely on MandateBatchStatusUpdate and MandateChargeNotExecuted webhooks to track outcomes.