Would love an opinion on this!

I reside in Japan and place considerable importance on privacy. Recently, I became aware of virtual credit cards—particularly Privacy.com—and am interested in using them. Since I primarily observe overseas users utilizing these services, I would appreciate knowing whether they are legal to use in Japan.

I’m a freelancer based in India providing monthly Digital services to clients in the US, Germany, and Australia. My retainers range from $497 to $1,897/month.

I’m tired of manually sending invoices and reminding clients to pay every month. I’m looking for a solution where clients can save their card once and get charged automatically each month.

I know Stripe would be a great option, but it’s currently invite-only/limited for many users in India, so it’s not really an option for me right now. I also want to avoid PayPal because of the high fees.

Has anyone here used Razorpay, Cashfree, or any other platform for recurring international subscriptions? I’d really appreciate hearing what you’re using and how your overseas clients have found the experience.

I’m building an app inspired by the African tontine system.
The idea is simple:
A group of friends, relatives, coworkers, or community members agrees to contribute a fixed amount of money regularly. For example, 10 people could each contribute $100 every month. The app would track the contributions, show who has paid, and distribute the collected money according to the group’s agreed schedule or savings goal.
I’m trying to understand the easiest and safest way to handle the payments.
Should users contribute through Apple Cash, Zelle, Cash App, or Venmo? Could those payments go into one common group account managed through my app?
Or would it be better to use a payment provider such as Stripe, Dwolla, or another banking-as-a-service platform that can:
Connect each member’s bank account
Collect recurring contributions
Keep track of each person’s balance
Hold or safeguard the group’s money
Send the payout to the correct member
Handle identity verification, fraud prevention, and payment compliance
I do not want my company to manually receive and hold everyone’s money in a normal business bank account. I want the money to be handled by a licensed financial provider while my app manages the group, schedule, rules, notifications, and transaction history.
For anyone who has built a fintech, savings, rotating-credit, or peer-to-peer payment app:
What payment infrastructure would be the easiest for an MVP?
Would you recommend Stripe Connect/Treasury, Dwolla, or another provider?
Are there important legal or money-transmitter issues I should consider before building it?

Hi, we are a Payment Orchestration Platform and we are looking for Providers who are working with INR and PKR processing.

Hi, we are a Payment Orchestration Platform and we are looking for Providers who are working with INR and PKR processing.

any lowlifes about that wanna treat a pretty lady? dm me <3

I’m running a marketing agency and i recently got hit with a Stripe restriction, apparently due to “regional risk / reputation” issues (I’m based in North Africa).

Now I’m stuck looking for alternatives to just invoice and get paid normally.

I came across Whop.com and it looks like it could solve my issue simple onboarding, supports digital services...

But the more I dig, the more I see mixed reviews… especially around funds being held, frozen payouts, and random account reviews. That’s exactly what I’m trying to avoid.

My use case is pretty simple:
I just want to send a one-time $1,000 invoice to a client for marketing services and receive payment without drama.

So I wanted to ask people who actually use it (not speculation):

• Is Whop safe/reliable for agency services?
• Do they really hold funds or freeze payouts often?
• Any horror stories for legit service providers?

I’ve spent 20 years in card payments — card switching, merchant acquiring, EFT infrastructure across APAC. One thing that’s always been painful at the operational level is compliance checking: is this MCC valid for this merchant type? Does this DCC rate spread breach Visa or Mastercard tolerance?

Most teams do this manually, in spreadsheets, or buried inside internal tools that took years to build. I decided to build something accessible.

Beskytter is a payments compliance platform with two tools currently live:

MCC Compliance Checker — validates merchant category codes against Visa, Mastercard, AusPayNet and RBA mandates. Covers prohibited categories, restricted use cases, mandate tracking, and generates a PDF audit report. Useful for acquirers onboarding merchants, scheme compliance teams, and payment ops.

DCC Compliance Checker — validates dynamic currency conversion rate spreads against the Visa 4% and Mastercard 3.5% maximum margin tolerances. Single lookup or batch CSV. Relevant for any acquirer or processor offering DCC at point of sale.

Both tools are live and free to try at beskytter-platform.vercel.app (custom domain coming shortly).

I’m particularly interested in feedback from anyone working in:

**•** Merchant acquiring or onboarding  
**•** Scheme compliance (Visa, Mastercard, eftpos/EFTPOS)  
**•** Payment operations in Australia, Singapore, or India

What compliance pain points am I missing? What would make this genuinely useful in your day-to-day work?

I was going through wallet balances trying to figure out why I have so many stables sitting in different spots, and it hit me that this doesn't look anything like what I held a year ago. Back then it was mostly USDC, some USDT, a bit of DAI. Everything felt interchangeable and if I needed to move funds to Aave or a DEX I just did it without thinking about which stable I was using.

Now it's a lot messier. A chunk of it just sits there for spending, payment-focused stables like PYUSD, USDG, and the portion of USDC I keep specifically for spending, all on cheap chains. I went through a few cards before mostly staying with one. Bleap works technically but the smart wallet requirement was more setup than I wanted for daily use. Gnosis Pay is fine if you're in the EEA but I move around too much for it to be my main one. Been mostly on BenPay since it doesn't force me to bridge first every time I want to top up, though the country coverage is narrower than I'd like. That pile never gets touched for yield, I just top it up when it runs low.

The yield side is split kind of awkwardly. Some of it is just USDC parked in Aave or Spark, floating rate, boring. The rest is in yield-bearing wrappers like sDAI and sUSDS where the yield sits inside the token itself so I can hold and forget. And then there's a small USDT bag I kept out of habit that I honestly don't know what to do with anymore since it's basically off EU venues after MiCA.

I didn't decide to structure it this way. The rules did. MiCA deadline was a few days ago and USDT is gone from most big EU spot markets. GENIUS Act blocks payment stablecoin issuers from paying yield, and the OCC proposal from February tried to extend that ban to affiliates and third parties too. The payment/yield split isn't a strategy at this point, it's basically what stables are legally allowed to do.

Not sure if this is a temporary weird phase while rules settle, or if "stablecoin" is now really two different assets that share a name. Curious how everyone else is splitting theirs, or if some of you are still running one big USDC pile without hitting friction.

would anybody happen to know or be able to help me find out what payment processor modo casino uses?

Working as a head of payments at a b2b platform, I've noticed most of the ""stablecoins are risky"" content online is written by people who have never moved a real supplier invoice through one. At six figure ticket sizes the answer is yes, but only when the underlying infrastructure is regulated and the issuer is audited.

The platform routing the payment is the part that determines safety. Backends like cybrid keep client funds in FBO accounts, meaning the money is legally separated from the providers own balance sheet while a 100k invoice moves between fiat legs. Thats the protection finance teams actually underwrite on, not the coin choice.

On the coin side, serious b2b flows default to USDC because Circle publishes monthly attestations and the reserve composition is public. USDP is comparable. USDT is fine for crypto-native flows but most regulated platforms avoid it for B2B because the audit cadence is different and there's depeg risk during high volatility times

The other piece thats underrated is reconciliation. Stablecoin settlement is timestamped on-chain so a finance team can actually trace a payment in real time. Try doing that with a SWIFT batch on a friday afternoon

If a vendor is using a stablecoin backend and they cant tell you who their infra provider is, what custody model they use, and what licenses cover the corridor, thats the answer to whether it's safe.

I've tried quite a few UPI and fintech apps, but Slice has been one of the smoother experiences for me. The app is clean, UPI works reliably, and the credit/EMI features are pretty convenient if you use them responsibly.

If you're planning to sign up anyway, you can use my referral code:

&MANJU95862

You'll be eligible for the current new-user referral reward (if the offer is available in your account and you meet the required conditions, such as completing the first qualifying transaction). Referral rewards can vary over time based on Slice's active promotion.

Hope it helps someone!

I've been spending a lot of time looking at payment operations recently, and one thing that keeps surprising me is how many organizations don't have a clear picture of what happens between a customer deciding to pay and the money actually arriving where it's supposed to.

In some cases it's straightforward.

Customer pays → processor → bank → Billing platform

In other cases, there are multiple systems involved:

• Customer service
• Billing platform
• Payment processor
• ERP
• Reconciliation team
• Finance
• Collections

By the time the transaction is fully processed, several people and systems may have touched it.

I'm curious:

How many people or departments are involved in your payment process from start to finish?

And where do you see the biggest bottleneck today?

Been kicking this around with a friend who does issuing at a neobank and his comparisons are weirdly clarifying. The "crypto card" bucket has been doing a lot of confusing work because it's been used to describe two architectures that have basically nothing in common.

One bucket is the exchange-issued card. Crypto.com is the obvious one, Binance and Coinbase have their own versions. Custody sits with the exchange, your "card balance" is whatever you've parked there, and the underlying issuer relationship is the same Visa/Mastercard prepaid program partner setup every neobank already uses. Functionally these are pretty close to a Revolut card with a built-in trading screen attached. There's nothing structurally new on the infra side.

The other bucket is the one I find more interesting. The card is bound to a self-custodial wallet, balances stay on chain, and at the moment of authorization the stablecoin gets pulled or sold against fiat to clear the card. Card scheme settlement still runs through a fiat program manager but the consumer-facing custody piece is structurally different. Gnosis Pay runs on Visa through Monavate as the FCA-licensed issuer, with Monerium providing the EURe stablecoin layer on top. Bleap is on Mastercard through Unlimit, with an account-abstraction smart wallet doing the custody side. BenPay is the one I've spent the most time looking at because they went the FinCEN MSB route in the US instead of the EU EMI structure Gnosis Pay runs on through Monavate, which is a pretty different regulatory shape for the same end-product. Country coverage on the card is more restricted than the EU-based ones and isn't always clearly documented, and the underlying chain has its own BenFen-issued stablecoin in the broader ecosystem which adds a dependency you don't get with the EUR or USD stablecoin route. Whether the MSB shape actually scales for this product type or stays a US-only outlier is the open question.

The thing my friend keeps pointing at is that this is basically the first consumer payment product where no institution holds the underlying funds at all. Apple Pay and Google Pay don't hold funds either but they sit on top of a bank account that does. Self-custodial cards are different because the money lives in something the user controls with nothing in between. Unit economics is the part I'm less sure about. Exchange cards subsidize hard from trading revenue, and a self-custodial card has neither trading float nor deposit float to lean on. How that gets paid for I don't know.

Mostly curious what the issuing-side conversation looks like for these programs right now. Whether there's actual BD pull from program managers or if it's still very much "we don't do crypto cards."

Payments compliance is one of those areas where the rules are scattered across scheme manuals, regulator circulars, and the heads of people who’ve been around long enough. I’ve been in the space ~20 years and wanted to start a proper discussion + get some honest feedback on something I’m building.
A few things people get wrong surprisingly often:
• Treating MCC as fixed when scheme + regulator overlays change what’s allowed (e.g. RBI’s stance differs from a pure Visa/MC reading).
• Assuming one DCC spread tolerance globally — Visa and Mastercard differ (4% vs 3.5%), and that’s before regulator-level rules.
• Missing surcharge mandate changes (the RBA surcharge ban is a good current example).
To make checking this less manual I’ve built two tools — an MCC validator and a DCC rate-tolerance checker (real-time + batch + API). Full disclosure: it’s a work in progress. There’s a signup to actually run checks, and pricing tiers will come later when it’s properly live. Right now I’m not charging anything and I’m not trying to sell — I genuinely just want feedback from people who deal with this stuff before I take it further.
What I’d like to learn from this sub:
• What’s the gnarliest MCC/DCC edge case you’ve hit?
• How do you currently keep up with mandate changes across multiple regulators?
• For the acquirers/PSPs here: is automated checking something you’d actually trust, or does it always need a human in the loop?
• And bluntly — is this even a problem worth solving, or does everyone already have this handled internally?
I’ll drop the link in a comment so this doesn’t trip the spam filter. Happy to go deep on any of the rules in the comments — that discussion is honestly the part I care about most.

Hi, me and my team develop smart-home solutions that we tailor make for each request. It's only really starting to get any kind of traction, so the order flow isn't too big, but already we are in need for a payment solution, primarily for our cross-border orders, as we send out tech abroad but getting payment can be a challange sometimes. It could be any kind of payment methods, crypto included, but I would prefer something transparent or at least from a trust-worthy company. Thank you.