CODEWITHSUNDEEP
stripe-payments
Logister
Logister

Reputation: 1904

Minimizing charge frequency and declines

I have an app that behaves in the following way: users have sessions, lasting about 1-3 hours. During that session, users make an indeterminate number of purchases. Suppose further that some users can compensate other users for their purchases, e.g. as a user, I could pay for some percentage of your purchases. What I want to do is minimize the total number of credit card charges, and maximize the probability that all charges succeed.

Concrete Example:

There are two users and three time periouds: u1, u2, and t1, t2, t3 respectively. In t1, u1 and u2 make a $10 purchase. In t2, u1 makes a $20 purchase. In t3, u2 compensates u1 for $5 of the t2 purchase. The amounts are represented in this table:

    |  t1  |  t2  |  t3  |
----|------|------|------|
u1  | $10  |  $20 | -$5  |
u2  | $10  |  $0  |  $5  |

Simple Solution 1: Everyone gets a charge!

Create a charge capture for the original amount each time someone makes a purchase and then simply charging less if someone's purchase is compensated. In this solution, the above problem results in 4 separate charges (one for each purchase and one for the 'compensation'). The problem with this is that, effectively, I am running four charges, but there were only three purchases. I am maximizing the probability of a successful transaction, but charges are not minimized.

Simple Solution 2: Sums

Save all purchases and payments in a database, aggregate them after t3, and then place single large charges for the aggregate amounts. The problem with this is that users may run up against account limits, and I don't know until I place the large charges. E.g. suppose u1 has $20 of credit, even if I check that each of his purchases will go through individually, the aggregate will fail. By the time that I aggregate, the user has already received what he purchased, and now I'm liable for the failed transaction. (Obviously not good.)

Complicated Solution 1: Everyone gets a capture!

When u1 and u2 make their initial $10 purchases, I create a $50 capture on each of their cards. Subsequent purchases in t2 get aggregated with the purchases in t1. Hence, u1 and u2 both have a single charge of $25 and $15 respectively. This is nice in that payments success is high, and I'm only running two charges. The problem with this is that I don't know what amount to capture at t1. Suppose that subsequent t2 purchases exceeded the captured amount; now I have to create new charges in t2 and we are back to the simple solution 1.

Complicated Solution 2: Rolling sum captures

In t1 create captures for each of the user's purchases. In t2, refund the captures made in t1 but then aggregate the t1 and t2 purchases into new captures. Repeat in step three. Hence, in t1 each user has a $10 capture, in t2 those are refunded and replaced by a $30 and $10 capture, in t3 they get a $30 and $15 capture. After t3 is finished, they get a $25 and $15 charge. This seems like the best solution, but there are a lot of captures and refunds, and maybe this is bad for some reason that I don't understand yet.

Are there better/other solutions to this situation that I haven't thought of? Is there something wrong with complicated solution 2 that I cant see?

Upvotes: 0

Views: 45

Answers (1)

Ywain
Ywain

Reputation: 17533

Complicated Solution 2 should work, although there's a risk that making too many charges on the same card in a short period of time could trigger fraud detection algorithms.

I'd recommend reaching out to Stripe's support directly at https://support.stripe.com/email. They have specialists that should be able to help you decide on the best payment flow for your app.

Upvotes: 1

Related Questions