Two providers on one Ghost site sounds like something you would only do while migrating, and reluctantly.
It is a normal configuration, it falls out of how Ghost is built rather than out of a workaround, and there are good reasons to stay in it permanently.
Why it works at all
Ghost’s member record stores who somebody is and what tier they hold. It does not store which provider paid.
That omission is the whole feature. A membership is a state, and any number of things can put a member into that state as long as they hold a valid Admin API key. Ghost’s own Stripe billing is one of them, and it is not privileged.
So two providers is not two systems glued together. It is two sources writing to one member list that was designed to be written to.
Why people end up here
Migration. The most common route. Existing subscriptions run out at the old provider while new sales go to the new one, and the overlap lasts a month or a year depending on billing period. The migration playbook.
Payout coverage. One provider reaches customers or countries the other cannot. Offering both is the difference between a sale and no sale for that group.
Different products. A recurring membership through one provider, one-off purchases through another that handles them better.
An audience that already exists somewhere. Patrons on Patreon and direct subscribers elsewhere, both landing on the same tier in Ghost. Neither audience has to move for this to work.
The last three are not temporary states. They are reasons to keep both running for good.
Map both to the same tiers
The instinct is to create a tier per provider so you can tell them apart. Resist it.
Tiers are what gates content, decides who gets which newsletter, and drives every audience filter you will ever write. Splitting one product into two tiers by payment method means every gate, every send and every count has to remember both, forever, and something will eventually forget one.
Map products from both providers to the same Ghost tier. A member is a member. If you need to know where they came from, put that information somewhere designed to hold it, which is the next section.
Four things to watch
Duplicate subscribers. The same person paying through both providers, usually after a migration where you asked people to move and they did not cancel the old one.
Ghost shows one member, because the email matches. Both providers keep charging. They will find out and it will be your problem regardless of who clicked what.
Nothing detects this for you. After any migration where you asked people to move, compare the active subscriber lists at both providers by email address, and cancel the old one yourself rather than waiting to be told.
Cancellation from the wrong side. Follows from the first. If somebody is paying through both and one subscription ends, that cancellation removes the membership while the other subscription is still being charged.
Rare, and unpleasant when it happens, because the person is paying and locked out. Another reason to clear duplicates rather than leaving them.
Reporting that no longer adds up. Neither provider’s dashboard knows about the other, so neither can tell you what you earned. Ghost cannot either, because it does not track money.
Nothing to fix here, just something to know before you spend an afternoon working out which dashboard is lying. Neither is. The answer is the sum, and it is a manual sum.
Turning one off too early. When the overlap is a migration, the old connection has to stay live until the last subscription through it has actually ended, not until you stopped selling through it.
Disconnect it early and the final cancellations arrive nowhere. Those members keep access they stopped paying for, and nothing tells you, because from Ghost’s side nothing happened. More on that.
Knowing where a member came from
Ghost does not record it, and there is no field to add for it.
Two workable approaches.
The event log, at the point of purchase. Accurate and awkward: it answers “where did this member come from” one member at a time, which is fine for support and useless for a list.
Labels, applied when the member is created. This puts the information on the member record where Ghost’s own filters can reach it, so you can email everyone who joined through one provider, or count them.
Labels are worth setting up before you need them. Retrofitting means matching a provider’s subscriber list against Ghost by hand, which is exactly the job you were trying to avoid.
Ghost still wants Stripe connected
Whatever combination you run, Ghost hides its membership settings until a Stripe account is connected.
The requirement belongs to Ghost’s settings screen rather than to any payment path. Connect any Stripe account and leave it idle if nothing is billing through it. The tiers everything above depends on live behind that screen.
If you cannot open a Stripe account at all, the arrangement still works, and it works differently enough to read about before you build on it: access is carried by a label on the member rather than by Ghost’s own paid status. Both cases.
Test the second one properly
The first provider being wired correctly says nothing about the second, and the specific failure to expect is a missing mapping: the event arrives, verifies, is understood, and grants nothing because no mapping exists for that product.
From outside, that is indistinguishable from a broken connection. The four causes when a payment produces no member.
Buy one thing through the second provider, watch the member appear on the right tier, then cancel it and watch the access go away. Twenty minutes, and it covers the case where two things that both work individually do not work together. The full checklist.