Grow's payment flow has a step most integrations get wrong: after the callback, your server must call approveTransaction. What createPaymentProcess and approveTransaction actually do, what the sandbox cannot test, and why instalments change your accounting.
Key takeaways
- The name changed. Meshulam is now Grow, and documentation lives at developers.grow.business - searching the old name returns older material that may not match the current interface.
- The flow is two-step: createPaymentProcess opens the payment page, and after the callback your server calls approveTransaction. Grow's docs require that second call as an acknowledgement and state the transaction is processed even without it - it does not move the money, but skipping it puts you out of spec.
- Instalments are a first-class feature in the Israeli market and they change your bookkeeping. Decide with the accountant whether the document reflects the full amount or the instalment, before you build.
- The callback is the source of truth, not the browser. A customer who closes the tab after paying never returns to your page, but your server still hears about it.
The first thing worth knowing is that the product name changed: Meshulam is now Grow, and the developer documentation lives at developers.grow.business, linked from 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:
createPaymentProcess- your server creates a payment process and receives a payment page you can embed in an iframe or redirect to.- The customer pays on Grow's page. Card details never pass through you.
- Grow notifies your server via callback.
approveTransaction- your server approves the transaction.
Step four is what most people miss. Grow's documentation says you must call approveTransaction once the server-to-server update arrives, and describes the call as your system's acknowledgement that it received the notification and knows the transaction status. The same page states that the transaction is processed even if the call is never made or fails - so it is not what moves the money. An integration that skips it still looks fine in testing, and is simply out of line with what the provider requires, which is a poor place to be when a dispute or a support ticket comes up.
Why the second step is still worth treating as a checkpoint: it is the natural moment for your server to validate before it marks anything paid - 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 mark the order paid - 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.
Which identifiers does the Grow API ask for?
A direct Grow integration identifies every payment request with two values Grow issues during onboarding: userId and pageCode. A platform that collects on behalf of several businesses adds an apiKey, and then sends the userId of the business being paid and the pageCode of the payment method. Each environment has its own set of values.
| Value | When it is sent | What to do with it |
|---|---|---|
userId | Every request | Server-side secret, one per environment |
pageCode | Every request, per payment method | Configuration, not code |
apiKey | Multi-business setups only | Server-side secret |
processId, processToken | Come back when the process is created and again in the callback | Store on the order; later requests on the transaction, such as a refund, use them |
The payment link itself is short-lived: Grow's reference says the URL is valid for 10 minutes. Create it when the customer is about to pay, not when the order is drafted, and never send it as a "pay later" link.
What does the Grow callback look like?
The Grow callback is an HTTPS POST to the notifyUrl you passed when creating the process. The documentation is explicit that its parameters arrive the same way you sent them to the create call, not as JSON - a handler that only parses a JSON body reads an empty request and drops a real payment.
The fields in the documented sample that matter for reconciliation:
transactionIdandasmachta- Grow's transaction id and the card authorisation number.sum,paymentsNum,firstPaymentSum,periodicalPaymentSum- the total and the instalment split, which the accounting question below depends on.statusCode,cardSuffix,cardBrand- for the receipt and the support log.customFields- the custom fields you sent (the sample showscField1), the natural place to carry your order id.
To test the handler without paying, the sandbox has an updateMyUrl call that sends a sample callback to the URL you give it.
Does Grow have a sandbox, and what can you not test there?
Yes. The Grow sandbox base URL is https://sandbox.meshulam.co.il/api/light/server/1.0/ - the old name survives in the address - and the live environment is opened only after Grow confirms development and testing are complete. The documented test cards are 4580458045804580 (single payments only, and useful for forcing a failure on an instalment payment), 4580000000000000 and 4580111111111121.
The trap is the payment methods that have no test environment at all:
- Bit, Google Pay and Apple Pay - Grow states they run as real, charged transactions even during development.
- PayBox - cannot be completed in the sandbox and is available in production only.
- Apple Pay inside an iframe - needs domain verification first.
So plan one small real payment per wallet before launch, and decide in advance who refunds it.
Callback or webhook: which one does Grow send?
Both exist, and they are different things. The callback to notifyUrl belongs to a payment process your server created. Grow webhooks are a separate feature that support enables on the account, with events you pick: one-time transactions from any page or source, specific payment links, WordPress plugin sales, recurring charges from the second charge on, a failed recurring charge, POS device payments, invoice creation and Grow app transactions. If the business also sells through a Grow payment page or the app, only a webhook tells your system about those sales. The webhooks guide describes a webhookKey in the payload but no signing scheme, so confirm each event against your own order and amount before acting on it.
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
- Open the documentation at
developers.grow.business- do not search for "Meshulam", the name changed. - Confirm
approveTransactionis called on every successful path. This is the most commonly missed check. - Test the case where the customer pays and immediately closes the tab - did the order update?
- Test a duplicate callback - was the order marked twice?
- Get written confirmation from the accountant on how an instalment transaction is recorded.
- Confirm there is no double document issuance.
- Test a real failure, not only success.
For a comparison of the Israeli gateways, see Israeli payment gateways compared.
Sources
Frequently asked questions
Is Meshulam the same as Grow?
Yes - Meshulam rebranded to Grow, and the developer documentation is published at developers.grow.business. Searching the old name still returns results, but some of that material predates the current interface, so work from the official documentation rather than from an older example you find in a forum or blog post.
What does approveTransaction do in the Grow flow?
It is your server's acknowledgement, sent after the callback arrives, that it received the notification and knows the transaction status. The flow is createPaymentProcess, the customer pays on Grow's page, Grow calls your server back, and then you call approveTransaction. Grow's docs require the call, and also state that the transaction is processed even if it is not made or fails.
What should happen between the Grow callback and approving the transaction?
Validation. Cross-check the amount against the order server-side and do not mark the order paid if it does not match, confirm the order has not already been paid since callbacks can repeat, and log the full response before continuing. The two-step design exists precisely to give you this control point - it is worth using rather than marking orders paid blindly.
How should instalment payments be recorded in the accounts?
That is the business accountant's decision, not the developer's. Ask explicitly whether a document should reflect the full amount at the time of the transaction or whether each instalment produces its own entry - both have logic, and the answer depends on the business's reporting method. Your system must store both the total and the instalment count regardless, or the context is lost.
Should order status be updated on the Grow redirect or the callback?
The callback. The browser redirect depends on the customer staying on the page, and anyone who closes the tab as soon as payment clears never returns - leaving the order pending while the money was collected. Use the callback to update state and trigger approveTransaction, keep the redirect purely for a thank-you screen, and make the callback endpoint idempotent.
Does the Grow API have a sandbox?
Yes. The sandbox base URL is https://sandbox.meshulam.co.il/api/light/server/1.0/, with its own userId, pageCode and apiKey, and documented test cards such as 4580458045804580. Bit, Google Pay and Apple Pay have no test environment and are charged for real, and PayBox works in production only, so plan a small real payment for each.
Is the Grow callback sent as JSON?
No. Grow sends the callback as an HTTPS POST to your notifyUrl, with the parameters in the same format you used for the create call, and the documentation says explicitly that it is not JSON. A handler that parses only a JSON body sees an empty request, so read form fields such as transactionId, sum, paymentsNum and processToken.
What is the difference between the Grow callback and Grow webhooks?
The callback reports on a payment process your server created through the API. Webhooks are enabled on the account by Grow support and report events you choose, including sales from Grow payment pages, payment links, the WordPress plugin, POS devices and the app, recurring charges from the second one on, failed recurring charges and invoice creation.
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
Have a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.