Could Hyperswitch handle our upcoming crowdfunding platform?

[Erudition]

At Snowdrift.coop we are building a crowdfunding platform for Free/Libre/Open public goods.

We're using a novel funding mechanism called crowdmatching, which we're excited to try when we launch our Beta (Alpha is already running, using Stripe). I'll spare you the details here, since all I need to know if Hyperswitch can support a certain set of requirements. If so, we'll consider deploying the Hyperswitch Open Source offering (we require full-stack FLO). Appreciate any insights!

In a nutshell

Essentially, the crowdmatch platform works just like Patreon, without the exclusivity. The main difference is that the monthly payment is determined not (only) by the patron, nor by the "project" (recipients), but by the number of other people who pledge (decide to become a patron) to that project along with them. So a brand new project with few patrons gets very small donations, and if a project becomes popular, everyone automatically gives more.

Requirements

Store & Reuse of card (variable recurring payments)

So as you can see, we're looking for recurring monthly charges, but can't predetermine the amount (like monthly utility billing).

Stripe supports this, and it seems like Hyperswitch does too.

Card holds

On crowdmatch day (e.g. first day of new month) we want to ensure everyone's card is working and the funds are there, because patrons should only match other patrons who are actually donating. If any cards fail, we give them a few days to correct the situation before eventually dropping them from the crowd, which lowers the match rate (everyone pays a little less than the initial hold amount). So we need separate auth and capture to check all patron's ability to pay before the actual capture which may be less.

Stripe supports this, and it seems like Hyperswitch does too.

No escrow

At this time, we are not ready for the legal trappings of holding on to any money that is not intended for us, for any amount of time. In other words, when patrons are charged, it must go directly to the projects they patronize, without being in some sort of holding account. We realize this limits our options somewhat, especially since we're otherwise interested in the "wallet" approach that we could do with e.g. Dwolla.
Anyway, our platform can be thought of similarly to a platform such as Uber, where customer payments are split to pay a portion to the driver. Unlike Uber, however, we won't take a cut ourselves, ever.

Stripe lets us charge patrons and specify multiple recipients all through their Connect platform. Hyperswitch supports Stripe, so theoretically it does too, though from the documentation it's less clear if some of these features are missing, or how this might work if we use other payment processors too thanks to Hyperswitch.

Minimize fees, combine charges

Using a payment processor at all is a necessary evil and we'd rather all of the patron's donations go to their projects, but until that's realistic we are looking for the lowest-fee options that meet our needs. Stripe is not cheap at 2.9% + 30¢, but it's currently the most practical for our needs, and allows ACH for lower fees which we can offer to established patrons. Part of the issue is that projects are meant to start small, where 30¢ is already more than the monthly donation itself. Our current solution is to let those donations build up over months and only charge when the total fees are less than 10%. We also want to combine charges as much as possible.

Many-to-many payments

We can do all of our charges at once, so ideally we would charge multiple people in one go, and have multiple recipients (projects) in that charge. This would make the Stripe fees feel small. Unfortunately, Stripe doesn't support this, and there aren't really any platforms that do (besides wallet-style or crypto platforms).

One-to-many payments

So we must charge each patron separately, but as in the Uber example, we would at least like to make those charges be split among the relevant projects, so we don't get a separate 30¢ fee for each. This will help with the fees, and again, we can't store any money.
Stripe natively supports one-to-many transactions which is why it's our top pick right now. Using card holds with it does not seem to be an issue either. Does this mean Hyperswitch can do this as well?

Nice to have

These aren't requirements right now, but if Hyperswitch supports them it would certainly make it more appealing to switch from Stripe

Cross-border payments

Without compromising on the above process, if we could allow projects to have patrons in other countries, that would be phenomenal. At the very least, US patrons for European projects (and vise versa) would be a huge boon. Like many processors, Stripe loses most of its features when a payment tries to cross borders. I'm hoping that if Hyperswitch can't remedy this natively, the ability to link other payment processors would.

Pre-authorized Bank Debits

You can't do a "card hold" on a bank account with ACH, which is where the lowest fees are with Stripe. We can overcharge these users many days in advance and make up for it later, but the number of days is super variable, and if it goes through, it could get reverted at any time via disputes, not just within 30 days. (Perhaps years later?) ACH is US only, but according to your page it's the same elsewhere.

Crypto in and out

Stripe has limited support for crypto payouts but little to no support for crypto payments. Excited to see that Hyperswitch natively supports accepting crypto from patrons. Can the project be paid in crypto as well? Independent of the input currency?

[bernard-eugine]

Hello @Erudition . Thanks for reaching out!

Answers regarding your requirements below:

Store & Reuse of card (variable recurring payments)
If the underlying processor that you're going to use supports this, Hyperswitch will in turn end up supporting it too

Card holds - Supported by Hyperswitch

No escrow
It is a bit tricky here. Hyperswitch currently doesn't support the Marketplace/platforms solutions of processors like Adyen/Stripe directly as these solutions force the transactions to be locked within their ecosystem and thereby do not allow orchestration of payins/payouts across different processors.

Instead, Hyperswitch supports all the underlying components of these marketplace solutions through standalone features:

1. Multiple merchant ids/profiles: Create multiple merchant accounts under your Org in Hyperswitch for your sub-merchants and have a separate set of processors for these accounts if required and thereby replicating a marketplace setup
2. Payins/Payments: You can do payins/payments for your different sub-merchants through their own separate processors or through one single processor
3. Payouts: Manually trigger payouts to your different sub-merchants' accounts (card, bank, etc)
4. Reports and Reconciliation: Generate reports at sub-merchant level

Minimize fees, combine charges
From what we understand, Stripe also provides favorable rates for donations/NGO use cases. You might want to check with them about this. But yes, having multiple processors helps you negotiate better rates

Many-to-many payments - As you rightly said, this isn't a use-case that is supported currently by leading processors

One-to-many payments - This would be a setting at Stripe's end since Hyperswitch isn't involved in the settlement of money at all. As mentioned above, while we don't support Stripe Connect directly, you can use Hyperswitch to make payouts directly which could end up covering the split settlement use case that you're referring here

Cross-border payments - This again is a function of the payment processors that you integrate with and Hyperswitch has no direct role here. We support processors from across the world and we aren't restricted by the location of the merchants or customers.

Pre-verified Bank Debits
You could do pre-verification of bank debits by either doing micro-deposits verification (available in Hyperswitch through Stripe) or by using solutions like Plaid and Stripe Financial connections (not yet available through Hyperswitch)

Crypto in and out
Again this is a function of the underlying processors and the payment methods that you would want to integrate through Hyperswitch. We do currently support Crypto through Cryptopay and few other processors. You can check the list here

[Erudition]

Thanks for the detailed reply!!

You could do pre-verification of bank debits by either doing micro-deposits verification

Oops, I meant pre-authorization of a specific amount, which would change from month to month. Exactly the same thing as a "card hold" but for bank accounts. IIUC this is simply not possible, oh well.

All of your other answers were spot-on.

From what we understand, Stripe also provides favorable rates for donations/NGO use cases. You might want to check with them about this.

Ah, will do, though we'll be hosting projects which may use any kind of business entity, so many of the payments likely can't legally be considered "donations", and we can't be a 501 charity. We'll see though.

Payins/Payments: You can do payins/payments for your different sub-merchants through their own separate processors or through one single processor

Okay. So if we use Hyperswitch only with Stripe for now, we can use the multiple payout feature to have a single patron charge distributed to multiple projects (submerchants) without holding any money?

It sounds like that wouldn't work because it uses Stripe Connect, whereas having multiple separate payout transactions within Hyperswitch (but still using Stripe) would incur the stripe fee on each individual payout - eliminating the "combine charges" tactic. Do I have that right?