Grow (formerly Meshulam): The Two-Step Payment Flow Explained

The first thing worth knowing is that the product name changed: Meshulam is now Grow, and the developer documentation lives at grow.business/api-developers. Searching the old name still returns material, but some of it is dated and may not match the current interface - open the official docs rather than relying on an example you found.

The flow - and the difference that breaks integrations

The core pattern is two-step, and this is the part that matters most:

1. createPaymentProcess - your server creates a payment process and receives a payment page you can embed in an iframe or redirect to.
2. The customer pays on Grow's page. Card details never pass through you.
3. Grow notifies your server via callback.
4. approveTransaction - your server approves the transaction.

Step four is what most people miss. An integration that receives the callback, marks the order paid, and never calls approveTransaction will look like it works in testing, because the payment page reported success. In practice the transaction was not properly finalised, and it surfaces during reconciliation against the reports.

Why two steps exist at all: it gives your server a chance to validate before final approval - that the amount is right, that the order exists, that it has not already been paid. This is not bureaucracy, it is a control point, and it is worth using.

What to do between the steps

Once the callback arrives and before approveTransaction:

• Cross-check the amount against the order, server-side. If it does not match, do not approve - flag it for review.
• Check the order is not already paid. Callbacks can arrive twice.
• Log the full response before continuing. If something fails later, that is the evidence.

Instalments - the feature that changes your bookkeeping

Splitting into instalments (up to 12) is a first-class capability in the Israeli market, and unlike most features it is not merely a payments matter - it is an accounting one.

The question to put to the business's accountant, before writing code:

When a customer pays in 6 instalments, does the document reflect the full amount at the time of the transaction, or does each instalment produce its own entry?

Both approaches have logic, and the answer depends on the business's reporting method. What is not legitimate is the developer deciding alone - this determines when revenue is recognised.

The practical consequence: your system needs to know both the total amount and the number of instalments, and store both. If you stored only what was collected this month, you have lost the context.

The callback is the source of truth

As with every gateway - Cardcom, Tranzila, PayPlus - the browser redirect is not a reliable update mechanism.

A customer who closes the tab the moment payment clears, whose connection drops, or who simply does not wait, will not return to your page. If that is where you mark the order paid, it stays "pending" while the money has been taken.

The rule: the callback updates order state and triggers approveTransaction. The browser shows a thank-you screen. Never the other way round.

And the callback endpoint must be idempotent - the same notification can arrive twice, and that must not mark two orders paid or ship twice.

Who issues the document

The decision that recurs in every project connecting payments and accounting: if the gateway is configured to issue a document automatically and your system also issues one through your invoicing system, one transaction produces two tax documents.

It surfaces at month end, at the accountant's desk. Pick one side and document it before writing a line.

Security

• Do not touch card details. They are entered on Grow's page. Do not relay, log or store them - doing so pulls you into PCI DSS scope.
• Authenticate the callback. A public endpoint that marks orders paid and triggers transaction approval is an obvious target. Do not rely on the URL being secret.
• Server-side secrets only. The credentials authorise collecting money in the business's name - not in source control, not in logs, not in a browser.

Pre-launch checklist

1. Open the documentation at grow.business/api-developers - do not search for "Meshulam", the name changed.
2. Confirm approveTransaction is called on every successful path. This is the most commonly missed check.
3. Test the case where the customer pays and immediately closes the tab - did the order update?
4. Test a duplicate callback - was the order marked twice?
5. Get written confirmation from the accountant on how an instalment transaction is recorded.
6. Confirm there is no double document issuance.
7. Test a real failure, not only success.

For a comparison of the Israeli gateways, see Israeli payment gateways compared.