Straight answers

Three Payments of $397: The Pricing Shape We Don't Sell Yet

TL;DR

GoCushy supports exactly two pricing shapes today: one-time payments, and subscriptions billed monthly or yearly. It does not support split payments — three payments of $397, four of $250, the shape most higher-priced offers get sold with. The code for it exists and is deliberately locked. It stays locked until a refund can provably cancel the rest of the schedule. If your business depends on instalments, stay on your current platform. That is the honest answer and I would rather you get it here than after you have paid me.

Someone asks me this most weeks, usually in the same words: can I do three payments of $397?

No. Not today, not with a workaround, not on any payment rail. GoCushy does one-time payments and it does subscriptions billed monthly or yearly. That is the whole list.

This is a real gap, not a cosmetic one

I want to be careful not to soften this. Splitting the price is how most things priced above roughly $500 get sold to a course-and-coaching audience. It is not a nice-to-have on the pricing page, it is the mechanism that makes the sale happen at all. A seller who runs a $1,200 program on a payment plan is not asking for a feature. They are asking whether they can operate.

Right now, on GoCushy, they cannot. If that is you, the useful thing I can tell you is: do not switch. Keep the platform that runs your payment plans, keep taking the money, and check back later. There is no version of this where you migrate and improvise your way around it, and I am not going to pretend otherwise to close a sale.

If your offers are one-time purchases, or recurring plans, then none of this touches you and the rest of the product is ready. The use cases page lays out what those look like in practice.

Why it is locked instead of rushed

The instalment work is in the codebase. It is switched off on purpose, and two engineering realities are why.

An instalment price is its own number. "Three payments of $397" is not $1,191 wearing a different hat, and it is not a total divided by three. Sellers set instalment prices deliberately — the split usually costs more than paying up front, and the arithmetic almost never lands on a clean division. Any system that treats a payment plan as division produces charges that are wrong by cents or by hundreds, depending on the offer. Wrong charges are not a rounding bug. They are a support queue, a chargeback, and a buyer who no longer believes your numbers.

A refund has to cancel the remaining schedule. This is the serious one. Picture a buyer on instalment two of three who asks for their money back. You refund them. Next month, the schedule that nobody cancelled charges their card again. That single sequence is the kind of defect that ends a company's reputation — not because the money cannot be returned, but because the buyer now has to fight software to stop being charged, and they will tell everyone about it.

So the guard against it has to exist, and be proven, before the system is permitted to create a payment plan at all. Not after. Not alongside. Before. That is the condition on unlocking this, and it is the only commitment I will make about timing — it is being built carefully, and it opens when that guard holds.

The principle underneath

A payments feature that is 90% finished is not 90% useful. It is dangerous. The missing 10% is almost always the part that handles money going backwards — refunds, cancellations, failed retries, disputes — because that is the least fun part to build and the easiest to leave for later.

Money going forwards is the demo. Money going backwards is the product.

This is also why the shape of GoCushy matters here. Funds settle on your own Stripe, PayPal or Airwallex account and GoCushy is never the merchant of record. Your buyer's card is charged by you, and a bad schedule would be charging in your name, from your account, against your reputation. That is not a risk I get to take on your behalf to make a comparison table look fuller.

What to do with this

I would rather publish the gap than have you find it on launch day. When split payments open, they will open with the refund guard already proven — and I will write that post the same way I wrote this one.