Interac eTransfer
Let clients pay by Interac eTransfer instead of by card. You hold the time or the seat, check your own bank, and approve.
Download PDFTurning it on
Go to Settings and find the Interac eTransfer block. There are two things to set: the switch, and the email address that receives your transfers. Both are required. A switch turned on with no address does nothing, on purpose: an eTransfer option with nowhere to send the money is worse than no option at all, because the client believes they have paid.
One address, everywhere. If you already entered an eTransfer address for Single Bills, it is already here. The two are kept in step from one input, so changing it in either place changes it in both. You will never have one surface quoting an address you no longer read.
Nothing changes for anyone until you switch it on. Clients of a firm that has not enabled the rail see exactly what they saw before: card only, with no mention of eTransfer anywhere.
What your client sees
Once it is on, a second payment choice appears on your public pages: bookings, written consultations, personal invites, event registrations and Q&A sessions. Choosing it does not charge anyone and does not open Stripe. It holds the time slot or the seat and shows the client three things they need to get right:
The same three facts are emailed to them as well, so they still have them after they close the page. When they have sent the transfer they press I have sent the eTransfer, and that is the moment you are emailed.
The 48-hour rule. The option is only offered when the session or event starts more than 48 hours away. An Interac transfer can take a day or more to arrive, and you still have to see it and approve it, so anything sooner would be held past its own start time. When that is the reason the option is missing, the page says so rather than leaving a client hunting for it. Written consultations are the one exemption: they have no scheduled session, so there is nothing for the rule to measure.
Free bookings never see it. There is nothing to send, so there is nothing to offer.
The Awaiting eTransfer queue
Awaiting eTransfer appears in the sidebar once the rail is on. Everything waiting on you is there, bookings and event seats and Q&A seats together in one list, sorted so the one about to lapse is at the top rather than buried under the ones that are not.
Check your bank first. We cannot see your account, and that is the whole reason this queue exists. Approving is what releases the confirmation, the agreement, the calendar invite, the tickets or the join link, and any documents. Before the Approve button will work you have to tick a box confirming the transfer actually arrived. The box is enforced on our side, not just in your browser, and it is deliberate: the way this rail can be abused is a client pressing "I have sent it" without sending anything.
Rejecting. Reject cancels the hold, puts the time or seat back on sale, and emails the client with any reason you type. It does not move money, because none of it ever passed through us: the transfer would have gone straight from their bank to yours. If a transfer really did arrive and you rejected it by mistake, returning it is between you and the client, outside the platform. The client is told to reply to that email if they believe they did send it.
If two of you press Approve at once, only one approval happens. The second person is told the state changed rather than quietly re-sending everything a second time.
The 24-hour hold, and what happens when it lapses
A hold lasts 24 hours, and the clock restarts when the client presses "I have sent the eTransfer". That is on purpose: your 24 hours should run from the moment the money was actually sent, not from whenever the client happened to open your booking page.
While it runs, the time or seat is genuinely held. Nobody else can take it, exactly as if the booking were already confirmed. That is what makes the option honest to offer.
If it lapses. The hold expires on its own, the time or seat goes back on sale immediately, and the client is emailed, including a warning not to send the transfer if they have not already. Nothing is charged and nothing is refunded.
One thing specific to Q&A. Q&A sessions work on first-booker-sets-time: whoever registers first on an open date chooses the hour, and everyone else joins them. If that first person pays by eTransfer and the transfer never arrives, freeing their seat would not be enough, because the date would still be pinned to an hour nobody paid for. So when the hold lapses and no held seats remain, the session comes down with it and the date is open again. A session other people have already joined is never removed.
Event tickets and join links
An event ticket is the one thing on this rail that could be used before you have been paid, so it is worth being clear about.
A ticket reference exists from the moment somebody registers, because that is how we identify their seat. It is not a released ticket. Until you approve the payment, the ticket page shows Not active yet instead of a valid badge, and scanning it at the door is refused. The tickets themselves are only emailed once you approve, exactly as they are on a card payment.
The same is true of a Q&A join link and of every other deliverable: nothing leaves the platform on this rail until you have said the money arrived.
Fees
We take nothing. The money goes straight from your client's bank to yours and never passes through Stripe or through us, so there is no platform fee on an eTransfer payment. Stripe's own processing fee does not apply either, for the same reason.
Your own administration fee still applies, and you can set it separately. Under each of the six admin-fee rows in Settings there is a second control, "If paid by Interac eTransfer", with four choices: same as above, no admin fee, a percentage, or a flat amount. Receiving a transfer costs you nothing, so a firm that charges a card surcharge often waives it here. Setting it per row rather than once for the whole rail is what lets you waive it on Q&A and keep it on bookings.
Whatever the fee works out to, it is included in the amount the client is told to send, so there is never a second request for the difference.
