Nonprofit · Fundraising A US nonprofit educational institution

Recurring donation billing that knows when not to run

Salesforce / SOLA / Hebcal Hundreds of charges a day About six months in production

0

technical failures across 18,578 charge attempts, July to September 2026

55

consecutive days the process ran, with no missed day and no failure

How we tell these stories

We tell every case the same way: not just the challenge and the result, but how we designed the flow and solved it step by step. In automation, the "how" is what holds up in production. So it's the part worth reading.

The challenge

Before the process existed, collecting recurring donations was manual end to end.

Hundreds of donors a day, one card at a time, one amount at a time, against a payment terminal screen. This was not an hour of work: it ran for hours, sometimes across days, and every additional day pushed collection further away from the due date that had been set.

The amount was typed in by hand, payment after payment
The merchant account was picked by hand, based on the campaign the donation belonged to
What had already been collected and what had not was marked by hand, after the fact

The real cost was not the time, it was the exposure. Each of those three points is a place where a donor can be charged twice, charged the wrong amount, or not charged at all. In an institution that lives on recurring giving, a billing error is not an operational glitch. It is a breach of donor trust.

The constraint that isn't technical

The institution does not carry out commercial transactions on Shabbat or on Jewish holidays. A manual process protects that on its own, because the person running it is not at the office. An automated process does not protect it on its own, which is why this was an explicit requirement from day one, ahead of every operational requirement.

How we thought about it

The approach

One daily scenario that pulls every payment now due from Salesforce, sends it to SOLA for processing, and writes the full result back to the record. The first action of every run is not a data operation: it is a single question put to the Hebrew calendar.

The idea behind the build was that automation inside a religious institution has to keep the same commandments as the people it serves. This was not a requirement bolted on at the end, and not a line item in acceptance testing. It is the first step in the scenario, ahead of every query and ahead of every data operation.

01 · Before anything is charged

Every payment is marked pending on the record before it goes out. A failure mid run cannot produce a double charge.

02 · After a decline

One decline is not the end of the road. The payment returns to a retry cycle with a ceiling that lives in configuration rather than in code, and can be changed without touching the scenario.

03 · When something is missing from the setup

A record with no matching merchant account is closed with an explicit error code, rather than being quietly skipped.

The sentence that captures the approach: a process that collects money instead of people has to be more conservative than they are, not faster.

How we built the logic

Inside the scenario

The institution collects recurring credit card donations against due dates set in advance in Salesforce. The scenario runs once a day at a fixed hour and handles everything that has come due. This is not a webhook: it is a full financial process, with a conditional gate at the entrance and a separate decision for every payment.

The three systems in the scenario

Salesforce The source of truth. It holds the payments, the due dates, the payment instruments, the merchant account mapping and the retry ceiling. Every result is written back to it.
SOLA The processing itself. It receives an account key, a token and an amount, and returns a full response with authorization code, reference number and verification results.
Hebcal The Hebrew calendar. Queried at the start of every run about holiday dates, against the date in the institution's own timezone.

The gate and the routing

The Shabbat and holiday gate. The first action in a run is a code module sitting on the canvas. It works out the day of the week in the institution's timezone, and asks the Hebrew calendar whether the date is a holiday. Either answer is enough to stop the run there, ahead of any query.
Two day routes. A router separates Sunday from the rest of the week, because Sunday also clears the load from the day that did not run. In practice Sunday processes 1.6 times the payments of an ordinary day.
One query, two sets. Payments that came due today or yesterday, together with payments that soft failed in the last 5 days and are waiting for another attempt. Both are pulled together and handled by the same flow.

What happens to every payment

Marked before it goes out. The record is marked pending before the call to the payment gateway. A failure mid run cannot turn into a double charge.
Merchant account mapping. The campaign the donation belongs to is translated into the correct account key through a mapping table that lives in Salesforce, not in the scenario.
The charge itself. Sent as a token, never a card number, alongside the account key. The token on its own is not enough to charge.
Writing back. On an approved charge, 22 fields from the gateway response are written to the record, and the card token is replaced with the new token the gateway returned.
The retry ladder. On a decline, the attempt counter increases and the system compares it to the ceiling. Below the ceiling the record returns to pending and is picked up again tomorrow. At the ceiling it closes as failed, carrying the error code the gateway returned.
A safety net. Every system call is wrapped in an error handler: three attempts, fifteen minutes apart, completing the execution automatically.

Payments do not run in sequence but in parallel, and every charge attempt takes the transaction id as its own execution name. Two months back, any single donation can be opened to see exactly what happened to it, when, and how many times.

Why this couldn't be built easily any other way

Simple trigger-action tools break here

A conditional gate that depends on an external service before the flow even begins, routing by day of week, a query that unifies two different sets of records, a separate decision for every record, and a retry ladder that holds state across days. Point-to-point automation handles one step. This is a process.

Custom code would lock every change behind a deployment

The retry ceiling, the list of merchant accounts and the campaign-to-account mapping all change in the real world. Here they sit as records in Salesforce, and the logic itself is edited in a visual builder. None of them needs a developer.

The religious rule would not have survived as a comment in code

The requirement that the process not run on Shabbat or holidays is not an addition, it is the first module. Make Enterprise allows a code block to be placed as a module inside the scenario, so the Hebrew calendar check is a single bubble that anyone opening the scenario can see, rather than logic buried in a side service.

With money, visibility is not a nicety

Every charge attempt is a separate execution named after the transaction id, with a full log of what was sent and what came back. When you are collecting from donors, being able to open a single case and show exactly what happened in it is part of the product, not a debugging tool.

The results

11,673 donations collected in two months. Across a measurement window of July to September 2026, 13,535 unique payments went through the process and 86.2% of them closed as approved. 85.3% were approved on the first attempt, and the retry ladder recovered a further 125 donations that would have been dropped after a single decline.
18,578 charge attempts, zero technical failures. Every attempt completed as a clean execution. Declines are not missing from that picture: 6,905 of the attempts were declined by the gateway, and each was recorded to the record as a business outcome rather than a failure needing intervention.
55 consecutive days, with no missed day. The main scenario ran once a day at a fixed hour, and on the eight Saturdays in the window it stopped at the gate after a single operation.
2 minutes 42 seconds to collect a full day, at the median. On the day that sat exactly at that median, 343 donations were collected. A single charge takes 3.21 seconds at the median, from entering the process until the result is written to the record, and charges run in parallel rather than in sequence.
In place of what. In place of typing an amount by hand for every donor, picking a merchant account by hand, tracking by hand who was collected and who was not, and chasing by hand which failures deserved another attempt. And in place of relying on nobody being in the office so that collection would not run on Shabbat.

The process has been in production for about six months. The numbers here are the measurement window of the last two months, not the whole story.

Why Make Enterprise

Code as a module inside the process. The Shabbat and holiday gate is a code module sitting on the canvas like any other bubble. Enterprise allows code to be embedded inside the scenario, which is why the most important rule in the process is also the most visible one.
Logic edited visually. The retry ceiling, the merchant account mapping and the recovery window are changed in the builder or in Salesforce records, with no deployment and no dependency on a developer.
Error handling at module level. Every external call is wrapped in its own handler, with an attempt count and interval set individually. That is what produces 55 consecutive days without intervention.
Enterprise grade security. A process that touches payment instruments needs SSO, a dedicated environment and full audit logs. Make Enterprise provides that infrastructure, and here it is used to the full: the process works with tokens only and never sees a card number at any point.
Visibility down to the single transaction. Every charge attempt is a separate execution named after the transaction id, with a full log of what was sent and what came back. In donor collection that is a requirement, not a convenience.
Platinum Partner, one of five worldwide. This process was built, launched and is maintained by us, end to end.

Have an internal process like this?

A process that eats people's time but has no clear owner to build for it. That's exactly what Make Enterprise solves.