bit for Business and PayBox: What You Can Actually Automate in a Collection Process

Neither bit nor PayBox publishes a developer portal you can sign up to and start calling. Both reach a business through a licensed payment provider, and the interface you get is that provider's interface. That changes exactly what can be automated and what cannot.

What these are, and what they are not

bit and PayBox are consumer payment apps. They solve one problem extremely well: moving money from a person to a business without handing over card details and without reading numbers down a phone line. They are not a payment gateway, not an invoicing system, and not a billing engine.

The distinction that saves a week of work:

• A payment method is how the customer pays. bit and PayBox are payment methods.
• A payment gateway is what runs the transaction and returns you a structured answer. That is the payment provider.
• A billing engine is what knows who should be charged, when, how much, and what happens on failure. That is your system.

The confusion arises because the customer only sees the first stage, so the request arrives as "connect bit". What actually gets connected is a payment provider with bit enabled on it.

Is there a public bit developer API?

Checking the bit for business site in September 2026, there is no developer portal, no technical documentation and no access key on it. The page explains the product and routes the business to contract with payment companies, stating explicitly that this is subject to each company's terms, limits and costs, and to its own customer verification process.

What can be said with confidence:

• Onboarding happens with a provider, not with the bank. The business signs with one of the listed companies.
• The list itself is published on the page and includes, among others, Grow, Gama Payment Management, Keep, Upay, GiveBack of the Headstart group, Israel Toremet, ONE City, Cardcom and EasyCard.
• Payment providers present bit as a payment method inside their own product, so the call you write is a call to the provider.
• The page notes that receiving funds without amount limits is available, subject to the provider's processes and discretion.

So "does bit have an API" is the wrong question. The right question is "which payment provider does this business use, and is bit enabled there".

And what about PayBox for business?

PayBox presents a business collection offering built on a personal payment link, a payment button on a website and a QR code. The PayBox payment button was launched together with Grow, which means the same thing again: what gets embedded in your system is a component belonging to the payment provider.

The button's launch announcement describes support for payments, with standing orders and recurring billing presented as a future capability. That is precisely the kind of detail you must not assume: if you are planning a monthly subscription, confirm in writing with the provider what exists today rather than what was announced.

Why is automated recurring collection a completely different problem?

Because recurring collection means charging with nobody present. A consumer payment app is built around the opposite: the customer receives a request, opens an app, and approves. That is an excellent experience for a single payment and a structural obstacle for a subscription.

The bottom line: these are tools for initiated collection, not for quiet collection.

What you do use for recurring collection

• A card token at the payment gateway. The customer enters a card once, the provider returns an identifier, and you charge against it. That is the foundation of any subscription.
• A direct debit mandate through Masav. Suited to fixed monthly collection at volume, with its own lifecycle of approvals and returns.
• A card standing order through the acquirer. A separate mechanism, arranged with the acquirer.
• A combination. Plenty of businesses collect one-off payments by link and subscriptions by token, and that is entirely fine as long as both write to the same customer record.

What you can still automate around them

Even without a direct interface to the app, most of the manual work in a collection process is not the payment itself:

• Generating a payment link automatically from your own system through the provider's API, and sending it over WhatsApp or email.
• Matching a returned payment to the invoice and the customer record, instead of ticking it off by hand at month end.
• Staged reminders to a customer who has not paid, which stop the moment the payment lands.
• An internal alert when a payment arrives for an amount other than the expected one.
• A daily report of what was collected and what is open, broken down by collection route.
• Writing every payment to the same place, so that link collection and token collection do not create two versions of the truth.

This describes what is published on the product sites in September 2026, and is not advice. Capabilities, limits and costs are set in the agreement with the payment provider and change over time.

Related: automating recurring billing in Israel, direct debits versus card payments, integrating with the Grow API.

Sources

• bit for businesses and organisations - bit site
• PayBox for business - PayBox site