 | techsin101 on Aug 27, 2020 | next [–] loading across multiple providers won't alter the chargeback ratio so what is the point? |
|
| fooey on Aug 27, 2020 | parent | next [–] Chargeback ratio's are per account, but also have a minimum absolute threshold. So it's say, 2% chargeback AND at least 200 chargebacks before penalties kick in. In a past life I worked for a place who had a few hundred processing accounts to load balance it all out because their chargeback rates were way too high. If an account gets close, you just don't use it for a month, or you throw a bunch of "safe" recurring charges at it to dilute it, or you hold a batch and send them through right before the rollover. Lots of ways to play number games. Most of the execs did go to prison though, so don't take this as advice, but to be fair, the processors are the ones who told them to use those tactics. |
|
| stickfigure on Aug 27, 2020 | root | parent | next [–] Don't tease us like that! Sounds like a fantastic blog story. |
|
| fooey on Aug 27, 2020 | root | parent | next [–] It's even better than you think. In the process two state AG's lost their careers, multiple US senators were implicated, a bank collapsed, there was kidnapping, human trafficking and drug running, and in the end created urban legends of gold bars being buried in the mountains to hide it from being seized by the feds. I don't know of anywhere that has it all written out, but here's a related NYT story with a fair bit of it: https://www.nytimes.com/2013/06/16/business/in-utah-a-local-... |
|
| stickfigure on Aug 27, 2020 | root | parent | next [–] OH NO WAY! That guy played a role in the documentary Sons of Perdition, rescuing "lost boys" from the fundamentalist mormons. Sort of. I'd read that sometime after the movie release he was exposed as some sort of fraudster but this story just gets crazier... |
|
| folli on Aug 27, 2020 | root | parent | prev | next [–] They went to prison for load balancing, or how does this relate? |
|
| fooey on Aug 27, 2020 | root | parent | next [–] The technical reason was bank fraud for all the shell corporations they set up in the process. The bank claimed they had no idea they were all related, even though every application had the owners name on the paperwork. To be clear, it was a bad company. However, the bank 100% knew what was going on and the merchant accounts 100% knew what was going on. So long as they were making money, and chargebacks make them a lot of money, they were happy. In my opinion the people running the company were just naive enough to not know how to cover their asses as well as the money guys. |
|
| thinkingkong on Aug 27, 2020 | root | parent | prev | next [–] Gambling. |
|
| fooey on Aug 27, 2020 | root | parent | next [–] The business was just run of the mill "get rich on google" and "free government grant" garbage that was common in the 2000's. Ironically, they made so much money doing their regular business the owner bought a small US based bank and was running online poker processing through it. When "black friday" in the poker world happened, the bank failed and everything fell apart, but so far as I know, no one involved was ever charged with anything related. |
|
| PeterisP on Aug 27, 2020 | parent | prev | next [–] You can direct most of the payments towards the cheap-but-prudish processors, and the really adult stuff towards a processor that accepts almost anything but is more expensive. |
|
| capableweb on Aug 27, 2020 | parent | prev | next [–] You could (in theory) do some risk analysis and put the ones with the highest risk into the providers where you had the lowest chargeback. Wouldn't be 100% solution, but could get you there. |
|
| netsharc on Aug 27, 2020 | root | parent | next [–] I wonder if they do do that. In Germany there's a credit rating agency that more or less has a monopoly, and everyone has more or less a profile with data supplied by companies who've dealt with them commercially (e.g. if you signed a phone contract or opened a bank account). But sometimes their algorithm would also try to predict the chances of people not paying bills by things like the ZIP code where they live... |
|
| nasalgoat on Aug 27, 2020 | parent | prev | next [–] It spreads the chargebacks across multiple processors, who don't talk to each other so don't know about the chargebacks on the other processors. |
|
| vehementi on Aug 27, 2020 | root | parent | next [–] That still does not affect the ratio |
|
| sk5t on Aug 27, 2020 | root | parent | next [–] Maybe the confounding factor here is that the term "load balance" could be extremely unsuitable for onlyfans' processing logic; e.g. they might preferentially route the risky transactions to one or two processors that won't get too agitated/punitive. |
|
| pen2l on Aug 27, 2020 | root | parent | next [–] How is any given transaction distinguished as being risky or non-risky? |
|
| lovegoblin on Aug 27, 2020 | root | parent | next [–] Just off the top of my head, they'd have chargeback rate per-performer and per-customer. Or they may have some kind of internal scoring system that rates how "porn-y" a given performer is - maybe that correlates to chargeback rate. Who knows - I'm just spitballing. But there are signals one could look at. |
|
| mcphage on Aug 27, 2020 | root | parent | prev | next [–] If you've had multiple transactions with the same buyer with no chargebacks, you can probably put that buyer in a low risk pool. |
|
| nasalgoat on Aug 27, 2020 | root | parent | prev | next [–] The individual processors are the ones who care about chargebacks, not VISA itself. So by spreading the processing among several of them, the number of chargebacks per processor are lower. It's load balancing. |
|
| Quarrel on Aug 27, 2020 | root | parent | next [–] This just isn't true. Yes, you can be pinged by the processor, but mostly because they're worried about the CC networks pinging them. Source: Have a 30M+ people site that has been pinged by VISA itself for chargeback ratios ... |
|
| xuhu on Aug 27, 2020 | root | parent | prev | next [–] Also lower is the number of transactions. The ratio stays the same. |
|
| nasalgoat on Aug 27, 2020 | root | parent | next [–] From my experience in the adult industry, the processor cared more about the total than the percentage. |
|
| thomasedwards on Aug 27, 2020 | parent | prev | next [–] Stripe is cheaper than CCBill, so it makes sense to send more that way when you can. |
|
| Exuma on Aug 27, 2020 | parent | prev | next [–] Because MIDs also look at the total # of chargebacks and will do a manual flag review of your account, so they don't just look at the % ratio but also total number. |
|
| rebelidealist on Aug 27, 2020 | prev | next [–] "Last time I checked the network requests, I noticed it was storing the card on Stripe, CCBill, and Securion, but using CCBill or Securion to process the payment." Im curious about how to use Stripe to only store cards and let other processors make the charge. Would anyone have more info on this? Greatly appreciate it. |
|
| cj on Aug 27, 2020 | parent | next [–] > how to use Stripe to only store cards and let other processors make the charge 1) Have the user submit their card info on your payment page 2) Simultaneously send the card info to the 3 processors 3) Then process the charge through just 1 of the 3 processors, leaving the others open to be used later (At least with Stripe) the process of saving a credit card to Stripe and actually charging the card are 2 independent API calls. Nothing stops you from saving card info to your payment processor(s) without actually charging it. |
|
| m11a on Aug 28, 2020 | root | parent | next [–] To pull that off, they'd have to (technically) process the card info, which puts them in the scope for PCI compliance. By that point, I don't know why they'd send card info to 3 processors especially when they know, at that point, which processor they're gonna process it with. It would just make more sense to send it to the 1 processor the code ends up deciding to use. |
|
| cj on Aug 28, 2020 | root | parent | next [–] No, I don’t think that’s accurate. With stripe.js, you send the cc info directly to stripe from the browser. Stripe returns an identifier which you can use in the future to charge the card. Assuming other payment processors work similarly, you could easily send the credit card details to multiple payment processors directly from the browser to the payment processors, and then store the card identifiers from each processor (not the card number) in your database to charge it at a later date. |
|
| m11a on Aug 28, 2020 | root | parent | next [–] Stripe.js creates an iframe hosted by Stripe which sends the card information directly to Stripe. The merchant cannot see or intercept that card info, during or after transmission, and thus cannot send it to another processor (at least not using the same payment card input boxes). |
|
| cj on Aug 28, 2020 | root | parent | next [–] Ah yes, Stripe.js v3 works the way you described. I was thinking of Stripe.js v2 which doesn’t require an iframe / supports custom payment forms. |
|
| dylz on Aug 28, 2020 | root | parent | prev | next [–] I can't think of any payment processor that would allow this without 3 separate entries. They would be upset or bring you into PCI scope if you were modifying or tampering with their single input SDK to send cardholder data elsewhere. |
|
| sumedh on Aug 28, 2020 | root | parent | next [–] Dont know about Stripe but Braintree has a forwarding API where the card details go to Braintree then Braintree forwards that data to another payment gateway you have signed up for, the other payment gateway sends a token to braintree which forwards that token to you. Then you have an option to make the payment on Braintree or the other payment gateway using that gateway's token. |
|
| game_the0ry on Aug 28, 2020 | prev | next [–] > To reduce the likelihood of passing that chargeback threshold and being banned, OnlyFans uses "cascading payments", which essentially load balances the payments across multiple payment processors in order to reduce their chargeback ratios across their merchant accounts > I think Stripe is there for models on the site who don't sell adult content. OnlyFans probably does a check to see if the page is adult-related and if it is, then routes it to the correct payment processor. Very smart. |
|
| capableweb on Aug 27, 2020 | prev | next [–] Thanks a lot for the reply here. So Stripe manually checks the websites and sees exactly what they are being used for, as long as Stripe itself is not being used for the adult stuff, it's fine, and you can use other providers for the adult content? Still sounds like OnlyFans has some custom agreement with Stripe and a small player would get banned from using Stripe as soon as they see nudity on the site. |
|
| Rapzid on Aug 27, 2020 | parent | next [–] That sounds pretty reasonable; Stripe must be in a trusting arrangement with OnlyFans to do the right thing there. |
|
| mobilemidget on Aug 27, 2020 | prev | next [–] Stripe merchants are not audited by G2 LLC for MasterCard? (*edit, maybe not with all banks I think of after 'submit') https://www.g2llc.com/solutions/monitoring-solutions/merchan... In EU they do, and if a string, or image on the site is not 'okay', you get denied for processing. And that's website wide, not just a single page. So in that line, I don't understand how stripe does this 'on the radar'. |
|
| ardy42 on Aug 27, 2020 | prev | next [–] > I think Stripe is there for models on the site who don't sell adult content. OnlyFans probably does a check to see if the page is adult-related and if it is, then routes it to the correct payment processor. How would the bank even know that transactions for adult-content pages were routed away from it? Wouldn't they just all come in as "OnlyFans wants $20 from card XYZ?" |
|
| stu2b50 on Aug 27, 2020 | parent | next [–] I'm guessing it would be negotiated terms between all three parties. Onlyfans ensures in their contract that they only route non-adult payments to Stripe, Stripe tells Wells Fargo to chill. Maybe some audits along the way to keep WF happy. |
|
