Hacker News new | past | comments | ask | show | jobs | submit | JakeVacovec's comments login

We do have a pricing page however it's geared towards giving an estimation on how much additional we can generate for a merchant with our average improvement against industry average failure and recovery rates.

We tailor pricing to provide a double digit ROI since there's a huge range between each businesses metrics. For example, take two businesses with $4M MRR and one has a payment failure rate of 25% ($1m/mo) and the other has 5% ($200k/mo). We've found that Merchants are happiest with this approach as we also provide a free payment audit upfront to benchmark historical performance, estimate our impact, and set price. This way the benchmark, targets, and ROI are completely transparent.


Good feedback - if a potential customer's first interaction with us makes them nauseous that's not great :)


It's fairly easy to measure performance. For companies with 100's of thousands or millions in failed payments each month 5-10% performance gains have a huge impact. On average we're improving recovery rate by 21%. To hold ourselves accountable we offer customers a full-refund if they're not satisfied with gains. We haven't had to give a refund yet.


A few key areas where our differences are advantages (in our pov): 1. We handle recovery e2e (both retries & communications) 2. We provide detailed real-time analytics on performance 3. Higher ROI (cost less and are directly responsible for more recoveries) 4. They're competing to be the card vault (replace Stripe, Adyen, Spreedly, etc. vault) whereas our vision is revenue optimization from initial authorization to recovery (complimentary to any stack)


More often than not we can resolve the payment issue without any customer involvement. That's the ideal path. In many cases the system will delay sending communications if the chances of a recovery by retry drop below a certain level. It's best to avoid asking customers to do something if it may already be fixed. Your bank still may notify you but that depends on your country and bank.

We don't guess a customer's language. Typically our Merchants have a single default language but since our Merchants are global it's important that the various messages we send can be available in different languages. If they have multiple instances for different geo's we can segment by language.

Our transactional emails have incredible deliverability scores and extremely low spam rates. They come from the merchants domain and are lightweight to ensure they go to the right inbox vs. ending up in promotion. For transactional sms we handle the compliance and each Merchant get's their own dedicated #.

Regarding pricing, each Merchant has different volume, failure rates, and recovery rates. Since we guarantee our ROI we have to tailor our pricing to them. We're working to make it easier so this is helpful feedback.


Not that I'm aware of. Depending on your size we can provide a solid start up discount :)


It's a diminishing returns problem... If they charge 2.9% + $.30 as their standard pricing, they are only keeping a small % of that as the issuer (Chase) gets the largest piece of the pie and the network (Visa) takes their cut too. If each declined authorization costs Stripe $.25, each attempt chips away at their margin.


Git-based editor for web-apps.. we still see promise especially with AI capabilities but fintech is a much better founder-market-fit for us.


Since we deal with error/auth codes we figured it could work -- you don't think so :)


We focus on MIT (merchant initiated transactions) vs. CIT (customer initiated transactions). Paze seems like a dupe of Shop pay and Stripe's Link. We support both since they support recurring. If paze allows for recurring (unclear) then we will support them too.


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: