Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine standardized volume pricing for card processing #48

Closed
matin opened this issue Aug 29, 2012 · 11 comments
Closed

Determine standardized volume pricing for card processing #48

matin opened this issue Aug 29, 2012 · 11 comments

Comments

@matin
Copy link
Member

matin commented Aug 29, 2012

Balanced currently charges 2.9% + 30¢.

The 30¢ can't change since the card networks and acquiring banks charge this amount to Balanced. The 30¢ is a direct passthrough.

The pricing would work in the following way (per month). This is the standard model for tiered pricing:

  1. up to tier 1 amount: 2.9%
  2. for transactions that exceed tier 1 amount in that month: x%
  3. for transactions that exceed tier 2 amount in that month: y%

There are two steps required for this task:

  1. determine the tiers (no more than what is listed above)
  2. determine the pricing for each tier
@matin
Copy link
Member Author

matin commented Aug 29, 2012

PayPal pricing
PayPal pricing

I don't think it makes sense for Balanced to match this pricing. It's more difficult to provide card processing for marketplaces. Regardless, it's a reasonable benchmark from a large processor.

@kieftrav
Copy link

I agree that it's difficult to match pricing at those volumes, but what if you did it at a larger scale? Say $100,000+ monthly volume match 2.2% + $0.30?

I like the waterfall approach because then it removes issues when volume fluctuates significantly between months.

@matin
Copy link
Member Author

matin commented Aug 29, 2012

@kieftrav waterfall model is definitely the way to go. In general, I think your going in the right direction.

PayPal's internal cost is also different. One, it's pure merchant processing. Two, they have such large scale.

Balanced has done discount pricing for early customers on an ad hoc basis, but I want to make sure anything standardized is sustainable for us. If it doesn't make business sense, then it's hard to ... well ... sustain it.

@mahmoudimus is working through different models right now.

@kieftrav
Copy link

Awesome. Looking forward to seeing an update on this.

@matin
Copy link
Member Author

matin commented Aug 29, 2012

The main blocker on working on the models is getting Chase to give us full insight into everything. We're pushing them to move faster

@kieftrav
Copy link

Ahhh.... That makes sense and is understandable. Appreciate the explanation.

@jkwade
Copy link

jkwade commented Aug 30, 2012

@matin would we offer volume discounting for payout fees (25¢) as well?

@matin
Copy link
Member Author

matin commented Aug 30, 2012

You can create a separate issue for that if you like, but I think 25¢
is very reasonable for next day.

@kieftrav
Copy link

Agreed.

@matin
Copy link
Member Author

matin commented Apr 5, 2013

It hasn't been possible to standardize pricing; though, this is the ultimate goal.

Some customers process a disproportionately high number of American Express or international cards, which have a much higher cost than 2.9%. It's not possible to provide a discount for those customers. As a result, it's not possible to provide standardized volume pricing across all customers.

PayPal has been able to work around this issue through massive volume, which averages out the cost for all customers and by receiving discounted pricing from American Express and cost optimizations with international cards. Balanced is growing quickly, but we're still not at the same scale as PayPal.

@matin
Copy link
Member Author

matin commented Apr 5, 2013

Closing out this issue until it can be revisited in the future.

@matin matin closed this as completed Apr 5, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants