PAYMENTS FM

Building a Payments Business For Your Software Platform: Emi Keshler, Payabli

Nikita Skitev — Sat, 12 Sep 2026 15:31:12 GMT

In this episode, I spoke with Emi Keshler, Director of Partner Development at Payabli. We talked about what a successful embedded payments program looks like. We discussed buyer experience, merchant experience and everything in between.

State of Payments survey: It takes about four minutes, anonymous responses are welcome, and we will publish the results at the end of the year.

What a successful payments program means to you?

Success is having control over the program: reliable metrics, a forecast for the next quarter, and operational processes that support the payment volume.

For a first-year program, she suggests about 40% merchant attachment rate and 30–40 basis points of transaction margin as starting assumptions.

The margin figure also needs a clear definition. In Emi’s example, charging 2.9% against processing costs of 2.5% leaves a spread of 0.4 percentage points, or 40 basis points, on processed volume. A platform still needs to account for its own operating costs when evaluating the business case.

How to succeed with merchant onboarding

Track the merchant journey in enough detail to see where progress stops. A single onboarding completion rate will not show all of the important stages. An approved merchant can still need help before processing successful payments.

Onboarding applications started. Identify merchants who began the application and have not completed it. Give the team a defined follow-up process.
Underwriting pending. Watch which applications are waiting for approval and what information is missing.
Approved but not processing. Check whether the merchant has the equipment, configuration, migrated tokens, and training needed to begin.
Testing and early use. Separate small test transactions and occasional payments from regular processing.
Fully activated merchants. Define what business-as-usual usage looks like for the vertical, then measure it.
Dormant accounts. Continue monitoring merchants after activation so the team can investigate declining usage.

What it means for your team

Emi breaks the experience into three groups, each with a different reason to care about payments.

Buyers. They need appropriate payment methods and a straightforward way to pay. Repeated data entry, disconnected systems, and difficult service after the payment can affect whether they return.
Merchants. They need to take payments, issue refunds, and reconcile without unnecessary manual work. The number of clicks, training time, and movement between systems affect both efficiency and employee experience.
Back-office and finance teams. They need to understand the economics and the value to the business. Their questions concern the return on investment, the books, and the operating model.

The administrative experience deserves particular attention. Emi describes a veterinary practice employee finishing a long shift and then spending another hour looking for a small reconciliation discrepancy.

Her suggestion is to sit down and reconcile a day of activity the way an end user would. Include the payment methods they actually accept, such as cash, checks, ACH, and cards, and see where someone has to leave the workflow to find an answer.

What to do next

Walk through the full onboarding journey. Pre-fill information the platform already has, and account for the handoff between the person completing the application and the authorized signatory.
Explain the information request. Give merchants a short FAQ covering what is being collected, why it is needed, and what happens next.
Involve risk and underwriting early. Help the team understand the platform’s typical merchants before applications arrive, so it can recognize expected activity and investigate exceptions.
Prepare for activation. Start token migrations early, configure tools, and arrange training that fits the merchant’s environment. Card-present businesses may also need hands-on hardware setup.
Test the daily workflow. Check reliability under real working conditions and reconcile a representative day of transactions. Make sure the team understands refunds and other routine operations.
Assign payments ownership. Designate someone accountable for adoption, economics, and ongoing performance. Emi notes that a large platform with an existing merchant base may need a dedicated payments leader sooner than a new startup.

Questions to ask internally

Who owns payments performance after the integration launches?
How many approved merchants have reached regular processing?
Where does onboarding stop, and who follows up at each stage?
Can an employee reconcile a full day without manually combining information from several systems?
Can support demonstrate the features we sell and explain their value for the customer’s industry?
Does our business case include pay-in and payout costs, staffing, and the work required to increase adoption?
When a merchant prefers an off-platform method, have we measured the administrative work and reconciliation it adds?

Related episodes

Jo Phillips and Will Corbera, Payabli. The broader business of embedded payments for vertical software platforms. Why Vertical Software Platforms Are Becoming Payments Companies: Jo Phillips & Will Corbera, Payabli.
Joshua Silver, Rainforest. Payment models and ownership for software platforms. Payments For Platforms: Joshua Silver (Rainforrest).

ACH credits get earlier morning availability, and more

Nikita Skitev — Fri, 04 Sep 2026 19:26:59 GMT

But first, announcement. State of Payments survey: It takes about four minutes, anonymous responses are welcome, and we will publish the results at the end of the year.

News of the week

ACH credits should be available earlier in the morning

Starting September 18, receiving banks have to make all non-Same Day ACH credits available by 9 a.m. local time on the settlement date. Today, that 9 a.m. rule depends on whether the bank received the credit by 5 p.m. the prior day. Nacha is removing that condition.

This is mostly a bank operations change, but it affects anyone who sends ACH credits and tells customers when money will be usable. That includes platforms paying sellers, insurers sending claim payouts, marketplaces sending cashouts, employers using ACH payroll-like flows, and merchants issuing ACH refunds.

The practical impact is timing. Some next-day and two-day ACH credits may become usable earlier in the morning, especially credits that arrive in later ACH Operator files. Payment teams should check payout promises, support scripts, treasury reporting, and provider SLAs so “next day” means the same thing to operations, finance, and the customer. More info on Nacha website.

Subscribe now

Other news

Card network and fraud updates

ACH, account-to-account, and instant payments

Merchant operations and payment performance

Agentic commerce, stablecoins, and cross-border

Payments Substack posts

The Business of Payments for Software Platforms with Jo Phillips & Will Corbera, Payabli

Nikita Skitev — Fri, 28 Aug 2026 19:41:14 GMT

Jo Phillips and Will Corbera, co-founders of Payabli, joined PAYMENTS FM to talk about why vertical software platforms are becoming payments companies, how they think about risk and pricing, and what separates a payments program that works from one that fails.

State of Payments survey: It takes about four minutes, anonymous responses are welcome, and we will publish the results at the end of the year.

Why this matters

Vertical software platforms have been adding payments for close to a decade. Companies like ServiceTitan, Mindbody, and Toast did it early, moving off legacy processors and generic gateways into something built for their own industry.

The decision is easy to state and hard to execute. A platform has to decide how much of the payments business to own, how to price it, which risk model to use, and which of its industries actually need something more specialized than an off-the-shelf provider.

Jo Phillips and Will Corbera built the payments business at ServiceTitan before starting Payabli. Jo led sales there; Will had already built one of the industry’s first payment facilitators, focused on property management. Together, they turned ServiceTitan’s payments into a large revenue driver and a better customer experience, and that work is what led them to start Payabli.

Payments can be 20 percent or more of a platform’s revenue, but that number is not automatic. It depends on pricing, on the vertical, and on whether the platform built a genuinely embedded experience or just added a link to a third-party checkout.

Most platforms will not need to become a full payment facilitator. Understanding the referral, managed, and full PayFac options, and knowing which one fits, is one of the more consequential decisions a platform makes.

What to watch

Watch the signals that show whether a payments program is built to last.

Whether payments is sold as a feature or built as a full experience
Which vertical the platform serves, and how nuanced its unmet needs are
How risk is priced, and who is holding it
Onboarding friction and drop-off
GMV run-rate relative to the point where payments can support a dedicated team
Whether pricing reflects the value of the experience, or is set defensively low
Whether payouts to vendors and suppliers are part of the roadmap, not just acceptance

What it means for your team

Payments does not stay in one part of the org once a platform decides to build it.

Product owns onboarding and checkout. Engineering owns the integration and the reliability of money movement. Finance and revenue teams care about pricing and margin. Risk has to decide how much exposure the platform is willing to hold, and how that changes as volume grows.

Jo and Will describe this as a “crawl, walk, run” process. A platform can start with a lighter-touch integration and take on more control, and more risk, over time, without rebuilding the underlying stack. What has to be in place from the start is a clear owner: someone whose job is to manage payments as an ongoing business, not a project that ships once and gets left alone.

What to do next

Map which of the “three Ps” (pay in, pay out, pay ops) the platform already offers, and which are missing
Get a clear answer on how risk is priced today, and what changes at different volume tiers
Review onboarding for friction points before adding new payment features
Revisit pricing against the value of the experience, not just against competitors
Identify who inside the company owns payments as an ongoing operating responsibility
Decide, deliberately, whether referral, managed PayFac, or full PayFac fits the platform’s stage and risk appetite

Questions to ask internally

Are we treating payments as a feature or as a business?
Do we know how much of our revenue payments could realistically represent?
Who owns risk today, and does that match what we actually want to hold?
Is our onboarding flow a reason customers drop off?
Are we pricing payments to reflect the value of the experience, or just to win the deal?
Do we have anyone whose job is to manage payments day to day, or is it everyone’s part-time responsibility?
Have we actually compared referral, managed PayFac, and full PayFac against our own volume and risk appetite?

Guest perspective

Payments as a feature earns a platform the right to payments as a business, but it can’t just be a feature set — the product experience has to come first.
Payabli’s differentiator is the “three Ps”: pay in, pay out, and pay ops unified into one stack, instead of separate providers for cards, ACH, payouts, onboarding, and risk.
Who owns the risk is a business decision, not a fixed model — platforms can hold full risk, share it, or hand it to Payabli, depending on their appetite and the economics they want.
Payabli focuses on “need-to-pay” verticals — property management, government, utilities, education, healthcare, law, and insurance — where the last 20 percent of the need is hard to solve without deep vertical knowledge.
The two most common failure modes are a weak onboarding experience and underpricing payments because it was easier to sell that way than to build the case for a fair price.

Resources

Related episodes

Subscribe for operator-focused conversations about money movement.

Processing payments for insurance industry

Nikita Skitev — Sun, 05 Jul 2026 17:49:15 GMT

Insurance payments look like regular subscription billing on the surface. However the importance of payment statuses is quite different. A failed payment may cause the policy to lapse which creates a major event for the customers and carriers.

Getting insurance premium collection right means understand your customer profile to offer them the right payment method, a payment experience that fits each sales channel, and treating payment status as operational data.

Let’s discuss some key components of successful payments for insurance industry.

Request your numbers

If you want to see how much of your insurance payments are failing and how much you can recover, reach out for an audit:

Request Audit

Provide relevant payment methods

There is no default payment method for insurance. Offering the wrong method creates friction at enrollment. The right method depends on who the customer is, how they were sold the policy, and what environment they are paying from.

Some customers buy a renters or auto policy through a mobile app and expect to pay with Apple Pay in two taps.
Some are older homeowners who have always paid by check.
Some policies are sold by agents and they collect payment methods from the customer. In this case the tipical payment methods are cards and ACH.

It is a key to understand your customer profile before designing the payment experience.

Different sales flows require different payment setups

Insurance is sold through several distinct channels, and each one creates a different payment context.

Direct digital — the customer buys online or in-app, completes the flow themselves. Cards, ACH via Plaid or similar, and mobile wallets (Apple Pay, Google Pay) all fit here. The experience should be fast, the authorization captured at the point of sale, and the recurring setup confirmed immediately.
Agent-assisted — an agent quotes and binds the policy over the phone or in person. The customer may not be at a device. This requires a different payment setup: a virtual terminal the agent can use to capture card details, a payment link sent by SMS or email for the customer to complete on their own.
In some cases a paper check or a bank numbers are collected in person. Payment capture cannot depend on the customer being in an app.
In other cases, the payment methods are collected by phone using the MOTO mode.

The mistake is building one payment experience and assuming it covers all. Building payment infrastructure that supports each channel separately is more work upfront but reduces friction across the board.

A failed payment means no coverage

Unlike almost any other recurring payment context, failure here has an immediate consequence for the customer. The policy either lapses or enters a grace period (typically 10 to 30 days), depending on state and policy type. If the grace period passes without resolution, coverage ends.

This means an insurer needs to know in real time (not at month-end) whether a premium was collected.

If the ACH debit returns R01 (insufficient funds) on the 3rd, and the grace period is 10 days, there is a narrow window to re-notify the customer, re-initiate the debit, and confirm collection before lapse.

Renewal payments are harder than they look

Renewal billing looks like a subscription but behaves slightly differently. In most subscription businesses, a portion of customers manage their payment methods. Insurance customers generally do not. They set up auto-pay at enrollment and then forget about it. The result is that renewal periods generate a spike in returns from stale account data and closed accounts.

The regulatory layer

Accepting a premium from someone who has no relationship to the policy creates regulatory exposure and potential fraud vectors. The practical check is to verify that the account holder or cardholder matches the named insured or an authorized party before processing. In consumer lines the policyholder and payer are usually the same person.

There are also several rules apply directly to insurance payment operations.

NACHA thresholds. Any insurer originating ACH debits must keep overall return rates below 15%, administrative returns below 3%, and unauthorized debits (R07, R10) below 0.5%. Exceeding these triggers corrective action from the originating bank, up to suspension of ACH origination privileges.
Authorization. Written or electronic authorization is required before debiting a consumer’s bank account. For recurring payments, the authorization must specify the payment schedule and give the consumer a clear path to stop payments.
State grace period laws. Most states mandate a minimum grace period before lapse for non-payment. Billing retry logic needs to be designed around these windows, not against them.
PCI DSS. If the insurer stores, processes, or transmits cardholder data, PCI compliance applies. Most insurers delegate this to a compliant processor, but the compliance obligation does not transfer with the data.

Next steps

Audit your ACH performance.
Reach out to us to audit your payments performance.
Review our guide on ACH payments recovery

ACH Recovery Framework

Nikita Skitev — Sun, 21 Jun 2026 20:55:00 GMT

When an ACH payment fails, many teams don’t retry or retry it once and move on. Some of those payments are recoverable and some are not. Treating them the same way leaves money on the table and can create compliance problems. This guide is the framework I use to work through them.

What this guide covers

This guide is about recurring consumer ACH debits: the payments you collect on a schedule that sometimes fail. It does not cover one-off transfers, person-to-person payments like Zelle or Venmo, or cards, which are a separate rail. B2B and corporate debits follow the same logic with a few different codes, and I note those where they matter.

The framework

There are six steps, and they run in order. The first two prevent failures, the next three recover the money when failures happen, and the last one keeps the whole thing under control.

Authorize transaction. Get clean, provable consent.
Verify bank account. Validate the bank account before you debit it.
Classify refusal codes. Read the return code to understand what happened.
Retry payments. Re-collect the failures that can be recovered.
Adjust billing logic. Act on what the codes are telling you.
Monitor results. Watch your return rates over time.

1. Authorize transaction

Authorization is where most ACH problems are either prevented or created. Authorization is when customer gives a permission to charge their bank account. A weak authorization usually comes back later as an R10 (the customer says they did not authorize the payment). This is the return you most want to avoid, because it counts against the 0.5% unauthorized threshold from NACHA and signals a compliance or fraud problem.

Clean authorization means a few things:

Clear consent. The customer takes an explicit action.
The right terms. You capture the amount or how it is calculated, the frequency, and how to cancel.
A recognizable payment descriptor. The customer should recognize the charge on their statement.
A record on file. NACHA expects you to be able to store the authorization action for audit purposes.

Following these authorization practices help preventing most of the disputes on a first place.

2. Verify bank account

A large share of payment failures usually come from bad account details captured at signup. These show up as R02 (account closed), R03 (no account), and R04 (invalid number). NACHA’s rules already require a reasonable account-validation method for first use, so this is worth doing regardless.

Here are the common options, from strongest to weakest:

Instant verification (Plaid-style verification). Confirms the account is real and owned, often with a balance signal. Often it is the best experience and the lowest failure rate, for a small cost per check.
Validation services (Early Warning). Check account status and ownership. A good fit for manual pf flows with sales assisted flows.
Micro-deposits. Confirms the account is active, this process often take a couple of days.

On Plaid-style versus raw account entry: a linked account fails much less than a hand-keyed routing and account number. There are no typos, the account is confirmed open, and the balance signal helps avoid R01. If you collect raw numbers with no check, your return rate will be usually higher.

3. Classify refusal codes

Classify means sorting each failed payment by its return code, so you know what to do with it. When a debit fails, the bank sends back a return code that explains why. That code is the difference between a payment you can recover and one you should stop chasing, so it is worth capturing and reading every one.

To do this well, make sure you record the return code for every failed payment. The codes come back in the ACH return files from your processor or bank. Group them into a few buckets and watch the mix over time. A lot of one code usually points to a specific problem. For example, a lot large number of R01 is about timing or affordability. Codes R03 and R04 is about bad data captured at signup. R10 is about authorization.

Here are the codes that come up most often, grouped by what they mean.

Funds usually recoverable

R01 insufficient funds. The account is open but does not have enough money right now. This is the most common return.
R09 uncollected funds. The money is in the account but not yet available, often because a recent deposit has not cleared.

Incorrect Account Number

R03 no account or unable to locate. The account number does not match an open account.
R04 invalid account number. The number is structurally wrong, usually a typo.
R20 non-transaction account. The account is not set up to be debited, for example a savings or loan account with restrictions.

Account closed or blocked, no longer usable

R02 account closed. The account no longer exists.
R16 account frozen. There is a hold or block on the account.

Stopped by the customer

R08 payment stopped. The customer placed a stop payment on the debit.

Authorization, the ones that count against the 0.5% limit

R10 not authorized. The customer says they never authorized the payment.
R07 authorization revoked. The customer authorized it before but has since cancelled.
R05 unauthorized, wrong code used. A consumer account was debited with a corporate code.
R11 not in line with the terms. There was an authorization, but something did not match it, such as the amount or the date. This one is usually fixable.
R29 corporate not authorized. The corporate version of R10.

If you want to see decline codes classified for your business – request an audit

4. Retry payments

For insufficient or uncollected funds (R01 and R09), NACHA lets you reinitiate a returned debit up to two times within 180 days of the original settlement. That is three attempts in total.

Other return reasons are not really retries. They need a fix first, such as a corrected account or fresh authorization, and then a new entry. Unauthorized returns should never be retried.

Most recoverable failures are about timing, so retry when money is likely to be in the account:

Line up with pay cycles. The 1st, the 15th, and the end of the month are good targets when customer receive their pay check.
Use escalating gaps. Wait a few days, then a bit longer, instead of hitting the account repeatedly. Think about retry and timing logic that works for your business vertical.
Do not retry the same day. It wastes one of your two attempts.

If done well, around one in four of these failures will come back.

5. Adjust billing logic

Retrying only recovers the funds returns. Everything else needs a different action, and the return code tells you which one. This is where you adjust how you collect based on what came back.

Account not found (R03, R04, R20). The account details are wrong, so there is nothing to retry. Go back to the customer and ask them to re-enter or re-link their bank account. The important part is to send the new details through account verification this time, the same Plaid-style check or validation service, so you confirm the account is real before you debit it again.

Closed or blocked account (R02, R16). The account is gone or frozen and will not come back. Ask the customer for a different account, or move them to another method such as a card on file.

Unauthorized (R10, R07, R05, R29). Stop charging that account right away and do not retry. These are the most damaging returns, because they count against the 0.5% limit and can point to fraud. Reach out to the customer, find out what happened, and get a fresh authorization before charging again.

Stopped payment (R08). The customer told their bank to stop the debit. Contact them to understand why before doing anything else. Retrying around a stop payment is a quick way to lose the customer and raise your return rate.

6. Monitor results

NACHA sets return-rate levels that get your payment provider or bank attention. You want to stay under the thresholds:

Unauthorized: 0.5%. Covers R05, R07, R10, R11, and R29. This is the one that causes trouble fastest.
Administrative: 3%. Covers R02, R03, and R04.
Overall: 15%. Covers all returns.

If you cross these, your payment provider is obligated to look into it, and a sustained problem can cost you the ability to originate ACH at all. It helps to track rates by code and by customer segment, so you can see where they are coming from, and to watch the trend rather than a single number.

Bottom line

Most failed ACH payments fall into a small number of categories, and each one has a clear next step. If you authorize cleanly, verify accounts up front, read the return codes, retry the ones worth retrying, act on the rest, and keep an eye on your rates, you will recover more revenue and stay well inside NACHA’s limits.

If you want this run on your own data, I can do a free ACH recovery audit and show you where your money is going, what is recoverable, and where your return rates sit. You can book a short call, or just reply.

If you want to see your numbers, request an audit:

Get My ACH Recovery Strategy

Demystifying Open Banking and Pay-by-Bank with Anubhav Pradhan, ShiftMate

Nikita Skitev — Mon, 11 May 2026 18:30:25 GMT

Anubhav Pradhan from ShiftMate joined PAYMENTS FM to talk about open banking, pay by bank, merchant adoption, and what payment teams should look at before they scale it.

We are launching the State of Payments survey. It takes about four minutes to complete, and anonymous responses are welcome. We will publish the results at the end of the year.

Participate in Survey

Why this matters

Pay by bank sounds simple: lower fees, direct account access, and another way for customers to pay. In practice, merchants still have to earn the conversion.

Customers need to understand the flow. The bank connection has to feel safe. Authentication has to work. Refunds and support have to be clear. Finance needs to see the cost benefit after any change in conversion.

That makes open banking a product, payments, finance, risk, and operations topic at the same time.

What to watch

Start with the signals that show whether pay by bank works for real customers.

Conversion versus cards
Bank authentication drop off
Coverage by market
Payment cost by method
Refund handling
Dispute and support volume
Settlement timing
Repeat usage

What it means for your team

Open banking can be useful when the customer has a reason to choose it. That reason may be speed, a better account funding flow, lower cost shared with the customer, or a use case where cards are a bad fit.

Product needs to design the moment where pay by bank makes sense. Engineering needs reliable bank connections and fallback paths. Finance needs cost and settlement visibility. Support needs clear answers when a bank payment fails or a refund is requested.

What to do next

Before pushing volume, make the operating model clear.

Pick the markets to test first
Compare conversion by segment
Review failed authentication flows
Define refund ownership
Track support tickets
Measure net cost impact
Keep card fallback available

Questions to ask internally

Where does pay by bank improve the customer journey?
Which customers have a clear reason to use it?
How does conversion compare with cards?
What happens when authentication fails?
Who owns refunds and support cases?
Does the cost saving survive the full customer journey?

Guest perspective

Adoption depends on trust and timing. The payment method has to fit the customer moment.
Lower fees help, but merchants still need conversion, coverage, refunds, and support to work.
Bank authentication is part of the product experience. Drop off there can erase the benefit.
Open banking works best when teams measure the full journey from checkout to settlement.

Listen or watch

Resources

Related episodes

PAYMENTS FM helps merchants, platforms, marketplaces, and payment product teams understand how payments work in practice through podcast episodes, expert interviews, community conversations, and practical payments education. Subscribe for operator-focused conversations about money movement.

Who is a Payments Product Manager?

Nikita Skitev — Sat, 28 Mar 2026 17:45:15 GMT

The payments product manager role has become very popular in recent years. Companies are starting to understand the value of investing into payments and having a dedicated payments person to own the payments product. However, there is no common understanding of how much this role is product versus payments.

Product Manager VS Payments Manager

When a business experiences a need with payments, they open it in the product department. In reality, this role is not only product. It oversees multiple domain areas such as compliance, vendor management, risks, business development, and many more.

I noticed that the role is very different depending if it is in enterprise company or a startup.

Payments PM role in large companies

Enterprises or companies operating with an Amazon-style working framework usually hire based on aligning with their values and work principles. They are less focused on domain expertise. It is more important for them to hire a person who will fit with their culture and will be a successful part of the team. In this case, the payments PM can even be without payments expertise and still be successful in the role.

During the interview, they will be asking how you solved problems in the past. They will not be asking about your knowledge of fraud, chargebacks, payment networks, etc.

The questions you get in the interview are product questions:

Tell me how you made a tradeoff
Tell me how you made a hard prioritization decision
Tell me how you disagreed with a leader

However, this may really differ from what a typical payments PM does in real life.

Payments PM role in startups

In smaller companies, the payments product manager is usually a payments expert. It happens that this person also manages the payments team and the roadmap. In this case, the payments PM also owns payments compliance, authorization rate metrics, payments analysis, risks, onboarding, vendor relationships, and many more.

What are the payments PM skills?

Regardless of the approach, the payments product manager is a combination of payments and product management skills.

As a payments PM, you should be a very strong PM, and here is why:

Stakeholder manager. As a payments PM, you need to work with a lot of stakeholders and strong leaders. Internal stakeholders include risks, compliance, accounting, revenue, and finance teams. So your stakeholder management should be top notch.
Defending your strategy. Because everybody has an opinion on payments. Sometimes the company CEO brings ideas to the table. A strong PM can’t be reactive to every new insight and should have a strong, defensible strategy.
Data driven. Payments have a lot of data. A payments PM should understand what the key challenges are and how certain payment metrics affect business KPIs.
Business oriented. Payments directly affect business revenue. A payments PM should be able to create a business case and understand the impact of opportunities.

Payments expertise

Depending on the business model, the payments expertise required and the level of depth can be quite different. Let me outline some key areas that are usually required:

Transaction lifecycle. Understanding how a payment moves from authorization to capture, refund, and payout and what can go wrong at each step.
Payments compliance. Navigating requirements like PCI DSS, SCA, and regional regulations that directly shape what you can and cannot build.
Vendor management. Evaluating, integrating, and maintaining relationships with payment providers, including commercial negotiations and technical partnerships.
Payments metrics and analysis. Tracking authorization rates, decline reasons, chargebacks rate, and cost per transaction to identify optimization opportunities and measure business impact.
Fraud and risk management. Balancing fraud prevention with customer experience, knowing that every friction point you add to stop bad actors also affects good ones.

Soft skills

Payments PMs are often ICs, which means they don’t have direct authority over the teams they depend on. They need to be able to lead through influence and aligning stakeholders around a shared priority without owning the reporting line.

Payments work items are usually quite complex and span multiple systems. Being able to effectively partner with engineering for understanding technical constraints, speaking their language, and earning their trust is key to delivering reliably.

Bottom line

The payments PM role is quite interesting and challenging at the same time. To be successful in this role you need to excel in both product skills and payments knowledge. However, what will be a balance of one or another will depend on where you work.

If you liked this article you also may be interested in

Payments Education

We have some spots left in our payments courses. Go to the courses page and reserve a spot. We will contact you with a schedule a pricing options.

Payments Interviews

Here are some great interviews we host on Payments.FM

Thanks for reading PAYMENTS FM! This post is public so feel free to share it.

How AI Analytics Transforming E-Commerce Businesses with Andrei Rebrov, Finsi

Nikita Skitev — Mon, 16 Mar 2026 20:46:59 GMT

Andrei Rebrov from Finsi joined PAYMENTS FM to talk about AI analytics for ecommerce payments, how teams find payment problems faster, and what still needs human judgment.

State of Payments survey

We are launching the State of Payments survey. It takes about four minutes to complete, and anonymous responses are welcome. We will publish the results at the end of the year.

Participate in Survey

Why this matters

Ecommerce teams already have a lot of payment data. The problem is finding the signal quickly enough to do something useful.

A checkout change can move approval rates. A customer segment can perform worse than expected. A provider issue can look small in aggregate and painful in one market. AI analytics can help teams notice patterns faster, explain them in plain language, and decide where to investigate.

The value comes when analytics leads to an action: a test, a routing change, a checkout fix, a fraud rule review, or a better question for the provider.

What to watch

Use AI analytics around metrics that connect to revenue and customer experience.

Approval rate changes
Checkout conversion
Decline patterns
Segment performance
A/B test results
Provider anomalies
Data quality gaps
Actions taken after alerts

What it means for your team

AI analytics is useful when payment data connects to orders, customers, checkout behavior, and business outcomes.

Product can see where checkout flow changes affect payment completion. Finance can understand revenue impact. Risk and fraud teams can review rules with better context. Engineering can spot integration issues faster. Operators can triage payment problems without waiting for a manual report.

What to do next

Start with a small number of high value questions.

Pick the metrics tied to revenue
Connect payment and order data
Review data quality first
Use alerts for real decisions
Validate findings with operators
Track fixes after insights
Keep ownership clear

Questions to ask internally

Which payment questions take too long to answer today?
Can we connect payment data to checkout and order data?
Which alerts lead to action?
Who reviews AI generated findings?
How do we know a recommendation worked?
Is the data clean enough for useful analysis?

Guest perspective

AI analytics works best when it starts with clear business questions.
Payment data needs context from checkout, orders, customers, and experiments.
Teams should use AI to find patterns faster, then apply payment judgment.
The best test is whether analytics changes decisions and improves performance.

Listen or watch

Resources

Related episodes

Agentic Commerce with Colin Luce, CEO Basis Theory

Nikita Skitev — Sat, 20 Dec 2025 19:35:20 GMT

Colin Luce from Basis Theory joined PAYMENTS FM to talk about agentic commerce, tokenization, payment data security, and how teams can give agents useful access without giving away too much control.

State of Payments survey

We are launching the State of Payments survey. It takes about four minutes to complete, and anonymous responses are welcome. We will publish the results at the end of the year.

Participate in Survey

Why this matters

Agentic commerce changes the checkout question. A customer may ask an agent to research, choose, and buy. That creates new decisions around identity, consent, payment credentials, data access, and authorization.

Payment teams need to know where sensitive data appears, which systems can touch it, and what an agent is allowed to do before a transaction is approved.

Tokenization, vaulting, and permission design become part of the product experience, because trust depends on what happens behind the scenes.

What to watch

Map the flow before adding agents to payment journeys.

Payment data entry points
Systems with card access
Token coverage
Agent permissions
Consent capture
Authorization steps
Vendor data sharing
Compliance scope

What it means for your team

Agentic checkout will involve product, engineering, security, compliance, risk, and payments from the beginning.

Product needs a clear customer experience. Engineering needs controlled interfaces. Security needs to reduce sensitive data exposure. Compliance needs evidence around consent and scope. Risk teams need to understand what can be initiated by an agent and what requires the customer.

What to do next

Start with data access and permission boundaries.

Map the full payment flow
Tokenize sensitive data
Limit agent permissions
Define approval moments
Review consent language
Audit vendor access
Keep logs for review

Questions to ask internally

Where does sensitive payment data enter the flow?
Which systems can store or process it?
What can an agent do before customer approval?
How is consent captured and shown later?
Which tokens can be used, where, and by whom?
What changes in compliance scope?

Guest perspective

Agentic commerce needs payment infrastructure that keeps data controlled and useful.
Tokenization helps teams reduce exposure while still supporting new checkout flows.
Permissions matter as much as storage. Teams need to define what an agent can initiate, view, and approve.
The customer experience depends on trust, consent, and clear boundaries around payment credentials.

Listen or watch

Resources

Related episodes

Solving Payroll and Cashflow Challenges for Small Businesses, Dan Loomis, Gusto

Nikita Skitev — Fri, 12 Dec 2025 18:07:22 GMT

Dan Loomis from Gusto joined PAYMENTS FM to talk about payroll, cash flow, and how payment timing affects small businesses.

State of Payments survey

We are launching the State of Payments survey. It takes about four minutes to complete, and anonymous responses are welcome. We will publish the results at the end of the year.

Participate in Survey

Why this matters

For small businesses, payment timing is a real operating issue. Payroll has a deadline. Cash comes in late. Bills still need to be paid.

A failed payment or delayed transfer can create a messy week for the owner, the finance person, and the employees waiting to get paid.

This is why payments for small businesses need to be simple, visible, and predictable. The product should help the operator know what money is available and what needs attention before payroll runs.

What to watch

Start with the signals that affect cash flow and payroll confidence.

Payroll timing
Available cash before payroll
Failed or delayed payments
Invoice collection timing
Payment method cost
Billing support issues
Manual reconciliation work

What it means for your team

Payroll and cash flow touch product, finance, operations, support, and risk.

Product needs to make payment status clear. Finance needs reliable timing. Operations needs fewer manual steps. Support needs simple explanations when money is delayed. Risk needs enough control without slowing down good customers.

What to do next

Look at the moments where timing creates stress for a small business.

Map cash inflows against payroll dates
Show funding status early
Reduce avoidable payment delays
Track payroll related support tickets
Simplify billing and reconciliation
Give operators clear next steps

Questions to ask internally

Where do customers feel cash flow pressure?
Can they see if payroll is at risk before the deadline?
Which payment delays create support cases?
Which manual steps slow the team down?
Can finance explain timing without extra cleanup?

Guest perspective

Payroll is a trust moment for small businesses. The money has to move on time.
Cash flow visibility matters as much as payment collection.
Payment products should reduce stress for operators, not add another workflow.
The best experience gives the business owner clear status and clear next steps.

Listen or watch

Resources

Related episodes

International Payments: Viktoria Soltesz, PSP Angels

Nikita Skitev — Thu, 06 Nov 2025 16:04:17 GMT

Viktoria Soltesz of PSP Angels joins PAYMENTS FM for a practical conversation about international payments, provider setup, risk, compliance, and operational control.

State of Payments survey

We are launching the State of Payments survey. It takes about four minutes to complete, and anonymous responses are welcome. We will publish the results at the end of the year.

Participate in Survey

Why this matters

International payments can unlock growth, but they add work across providers, currencies, settlement, compliance, fraud, and reporting.

Viktoria talks about what happens when companies expand before the payment setup is ready for the markets they want to serve.

The conversation is especially useful for teams managing multiple PSPs, entering new countries, or trying to reduce payment risk without slowing down growth.

What to watch

Approval rates by market
FX cost
Settlement timing
PSP performance
Compliance friction
Fraud by region
Reconciliation issues

What it means for your team

International payments are operationally heavy.

Product needs local checkout coverage. Finance needs visibility into fees, FX, and settlement. Risk needs controls by market. Compliance needs clear responsibilities. Operations needs escalation paths when something breaks.

Without that structure, global growth can become harder to manage than expected.

What to do next

Review PSP coverage
Track cost by currency
Monitor declines by region
Document compliance ownership
Create incident paths

Questions to ask internally

Which markets are hardest to support?
Where do fees and FX change margins?
Which PSP owns each route?
Who handles compliance questions?
How fast can we diagnose an incident?

Guest perspective

Viktoria brings an operator view of global payments:

Local context matters in every market.
Provider selection should match business risk.
Compliance ownership needs to be explicit.
Reporting and reconciliation are part of control.

Listen or watch

Resources

Related episodes

PAYMENTS FM is for people building and improving payment products. Subscribe for practical conversations on payment strategy, operations, risk, compliance, monetization, fintech infrastructure, and money movement.

Payments Data for Business Success: Albert Drouart, Pagos

Nikita Skitev — Thu, 09 Oct 2025 18:41:10 GMT

Albert Drouart from Pagos joined PAYMENTS FM to talk about payments data, monitoring, benchmarks, AI, and how merchants can use payments data in day to day work.

Note: We are launching the State of Payments survey. It takes about four minutes to complete, and anonymous responses are welcome. We will publish the results at the end of the year.

Why this matters

Payment teams usually know when a provider is down. The harder question is what happens when the provider is up, checkout is live, and payment performance still hurts the business.

Good customers can get declined. Fraud rules can block too much volume. Retries can add cost. Chargebacks can move in one market. Fees can change in ways finance needs to explain.

This is why payments data needs a business context. Networks change. Issuers change. Customer behavior changes. Internal teams ship product changes. Revenue can leak quietly if nobody reviews the data with the right context.

What to watch

Payment teams should watch the signals that connect payments to revenue, cost, customer experience, and risk.

Approval rate by payment method and other parameters
Technical declines by provider, integration, and setup
Decline codes that affect retries and customer messaging
Fraud rules that block good customers
Chargebacks by segment and market
Payment fees and avoidable retry cost
Retry performance and recovery rate
Subscription payment failures after internal changes
Wallets, BNPL, ACH, and pay by bank performance
Market changes that affect authorization rates

What it means for your team

Payments data is useful for many teams.

Product needs it for checkout conversion and customer experience. Engineering needs it for integrations and releases. Finance needs it for cost and reconciliation. Risk and fraud teams need it for exposure and false positives. Operations needs it for incidents. Leadership needs it for revenue.

Albert explains why merchants need clean data, useful alerts, benchmarks, and enough context to decide what to do next.

This also applies to single PSP merchants. One provider still leaves many questions: approvals, declines, cost, chargebacks, fraud rules, issuers, payment methods, markets, and customer behavior.

What to do next

Start with the places where payment performance can quietly leak money.

Review technical declines every week
Compare approval rate by payment method and other parameters
Connect payments to customer, order, subscription, and revenue data
Check if retries recover revenue or add cost
Review fraud rules for good customers blocked
Track chargebacks and fraud by segment
Monitor payment fees with finance
Give product, finance, risk, fraud, operations, and engineering one shared view
Use benchmarks before assuming the issue is internal
Clean PSP data before adding more dashboards or AI workflows

Questions to ask internally

Where do we see payment performance drop before revenue notices it?
Can we tell if a decline issue comes from us, the issuer, or the market?
Do product, finance, risk, fraud, operations, and engineering use the same payment data?
Which retries recover money, and which retries add cost?
Which declines can we actually fix?
Which fraud rules block good customers?
Can finance explain payment cost changes quickly?
Do benchmarks show if the issue is internal or market wide?
Is the data clean enough for useful AI work?

Guest perspective

Payment monitoring should cover more than provider uptime. A provider can be online while approval rates, fees, fraud rules, or chargebacks move in the wrong direction.
Raw PSP data is useful, but merchants still need cleanup. The work often includes normalized fields, business context, duplicate removal, and links to customer or order data.
Benchmarks help teams avoid guessing. If approval rates fall, the issue may come from an internal change, issuer behavior, card network changes, or a broader market pattern.
AI is useful when the data is ready. Machine learning can help with detection and anomaly analysis. Generative AI can help summarize changes and explain likely causes.
The real work is turning payments data into operating information that teams can use.

Listen or watch

Resources

Related episodes

PAYMENTS FM helps merchants, platforms, marketplaces, and payment product teams understand how payments work in practice through podcast episodes, expert interviews, community conversations, and practical payments education. Subscribe for practical payments education and operator-focused conversations about money movement.

News of the Week: Stripe <> EBANX – Pix for Stripe merchants

Nikita Skitev — Sun, 17 Aug 2025 21:31:25 GMT

What happened

Stripe and Ebanx announced a partnership to enable the Pix payment method in Brazil for Stripe merchants.

The bigger picture

Stripe says that their merchants can accept Pix from Brazilian customers with settlement in the merchant’s domestic currency. This is very useful if you are not set up locally in Brazil.

https://docs.stripe.com/payments/pix

This is aimed at businesses expanding internationally and looking for growth in Latin America. Pix is a super-popular way to pay in Brazil.

Why this matters

In one of my previous roles, I did deep research on payment methods in Latin America and Brazil in particular. Boleto is still widely used, but Pix growth has been extraordinary and now leads the market.

EBANX is a merchant-of-record partner that helps companies accept local payment methods in Latin America and other regions without opening local entities.
A year ago, I already wrote that Zuora, one of the leading subscription platforms, enabled EBANX.

With the recent announcement, Stripe merchants get access to the most popular payment method in Brazil, and EBANX gets access to Stripe’s merchant base. Win-win.

What’s next

Stripe’s documentation highlights a few limitations to keep in mind:

Pix only. Even though EBANX can enable multiple local methods (including local card schemes), Stripe has enabled only Pix in this partnership. Merchants can still use the Forward API to process cards with EBANX.
No recurring payments (yet). Stripe is explicit that recurring flow isn’t supported right now.

Statement descriptor nuance. Stripe indicates EBANX appears as the recipient in customer bank statements for Pix.

I would love to see Stripe expand these partner-powered local methods beyond Pix (think local cards and other APMs in LATAM).

The Right Way to Integrate a Payment Provider: Michael Taylor, Checkout.com

Nikita Skitev — Fri, 18 Jul 2025 15:49:45 GMT

Michael Taylor from Checkout.com joined PAYMENTS FM to talk about payment provider integrations, launch planning, and the operational details that decide whether an integration holds up after go live.

State of Payments survey

We are launching the State of Payments survey. It takes about four minutes to complete, and anonymous responses are welcome. We will publish the results at the end of the year.

Participate in Survey

Why this matters

A payment provider integration can pass testing and still cause problems after launch. Real traffic brings edge cases: failed webhooks, missing reconciliation fields, retry loops, market gaps, support tickets, and reporting questions from finance.

The integration is a product surface. It affects checkout, authorization performance, settlement, refunds, risk controls, customer support, and future expansion.

Good integration work means deciding early what success looks like and who owns each part of the payment lifecycle.

What to watch

Watch the signals that show integration quality after launch.

Integration error rates
Authorization performance
Webhook reliability
Reconciliation fields
Retry behavior
Refund flow issues
Support ticket themes
Market readiness

What it means for your team

Provider integration work should include the teams that will live with the result.

Product needs to understand checkout impact. Engineering needs clean implementation paths and failure handling. Finance needs reporting and reconciliation. Risk needs data for rules and reviews. Support needs clear customer outcomes. Leadership needs confidence that the setup can support the next market or payment method.

What to do next

Build the integration around launch and post launch operations.

Define success metrics early
Test failure paths
Validate webhook handling
Check reconciliation data
Document team ownership
Review retry logic
Plan for new markets
Prepare support playbooks

Questions to ask internally

What does a successful integration mean after launch?
Which fields does finance need for reconciliation?
What happens when a webhook fails?
Which retries help, and which add noise?
Who owns customer support edge cases?
Can this setup support the next market or payment method?

Guest perspective

Integration quality shows up after real transactions begin.
Teams should define success metrics before implementation starts.
Failure paths, webhooks, retries, and reconciliation deserve as much attention as the happy path.
A provider integration should be designed for future markets and payment methods, not just the first launch.

Listen or watch

Resources

Related episodes

Payment Retries: Philip Pages (Redux)

Nikita Skitev — Sun, 29 Jun 2025 21:35:32 GMT

Philip Pages of Redux joins PAYMENTS FM for a practical conversation about failed payments, retry strategy, recurring revenue, and customer experience.

State of Payments survey

We are launching the State of Payments survey. It takes about four minutes to complete, and anonymous responses are welcome. We will publish the results at the end of the year.

Participate in Survey

Why this matters

Retries are one of those payment topics that look simple from the outside and get messy fast once you look at the details.

A failed recurring payment might be recoverable. It might need a different payment method. It might need better customer messaging. It might be a signal to stop trying.

Philip talks through how teams can use retry logic without creating extra cost, customer frustration, or avoidable support work.

What to watch

Retry recovery rate
Cost by payment method
Churn after failures
Issuer response codes
Stop payment signals
Retries per customer
Support tickets after failures

What it means for your team

Retries sit at the intersection of payments, product, finance, support, and customer success.

The right retry strategy can protect revenue. The wrong one can create fees, failed customer journeys, and confusing emails at the exact moment a customer relationship is at risk.

That makes retries a product and operations topic, not a background setting.

What to do next

Split recoverable and final declines
Tune timing by issuer
Compare recovery with cost
Improve customer messaging
Respect issuer stop signals

Questions to ask internally

Which declines should we retry?
How many attempts are too many?
What does each retry cost?
When do we contact the customer?
Who owns failed payment recovery?

Guest perspective

Philip brings a focused view on failed payment recovery:

Retry strategy needs business context.
Decline codes should drive different actions.
Recovery should be measured against cost.
Customer communication is part of payment performance.

Listen or watch

Resources

Related episodes

Payments For Platforms: Joshua Silver (Rainforrest)

Nikita Skitev — Mon, 28 Apr 2025 17:06:31 GMT

Joshua Silver of Rainforest joins PAYMENTS FM for a practical conversation about embedded payments, platform strategy, merchant onboarding, and risk ownership.

State of Payments survey

We are launching the State of Payments survey. It takes about four minutes to complete, and anonymous responses are welcome. We will publish the results at the end of the year.

Participate in Survey

Why this matters

If you run a software platform, payments can become a real product line. That also means real decisions around onboarding, support, liability, risk, payouts, and the merchant experience.

Joshua gets into the choices platforms face when they move from referral or reseller models toward owning more of the payment flow.

The episode is useful for product, payments, risk, operations, and leadership teams thinking through how far they want to go with embedded payments.

What to watch

Merchant onboarding drop off
Activation after signup
Support volume by merchant type
Risk and liability ownership
Disputes by segment
Payout timing
Payment margin

What it means for your team

Embedded payments touches almost every part of a platform business.

Product needs a smooth merchant experience. Engineering needs reliable integrations. Risk needs clear exposure limits. Operations needs support paths. Finance needs clean reporting. Leadership needs to understand the revenue and liability tradeoffs.

That mix is where payment strategy becomes company strategy.

What to do next

Pick a model that fits your maturity
Define risk ownership early
Track onboarding friction
Measure buyer and seller experience
Treat payments as a product capability

Questions to ask internally

Who owns merchant onboarding?
Who handles payment support?
Where does liability sit?
Which metrics show merchant health?
What would make payments worth owning?

Guest perspective

Joshua shares a platform-first view of embedded payments:

Payments can deepen the merchant relationship.
Risk ownership should be clear before go-live.
Onboarding quality shapes adoption.
Platforms need payment partners that fit their operating model.

Listen or watch

Resources

Related episodes

Benefits of Payment Orchestration: Zubin Vandrevala (Gr4vy)

Nikita Skitev — Fri, 21 Mar 2025 19:29:58 GMT

Zubin Vandrevala from Gr4vy joined PAYMENTS FM to talk about payment orchestration, routing, provider control, and how merchants should think before adding more complexity.

State of Payments survey

We are launching the State of Payments survey. It takes about four minutes to complete, and anonymous responses are welcome. We will publish the results at the end of the year.

Participate in Survey

Why this matters

Orchestration gives merchants more control, but control only helps when the team knows what it wants to improve.

A second provider can improve resilience. It can also add reporting work, routing rules, reconciliation gaps, and more vendor management.

The business case should be clear before the stack grows. Are you trying to improve approvals, reduce cost, support new markets, add payment methods, or reduce provider risk?

What to watch

Measure orchestration through business outcomes, not vendor count.

Approval rate by route
Cost by provider
Failover performance
Market coverage
Payment method coverage
Reporting consistency
Reconciliation quality
Routing rule complexity

What it means for your team

Orchestration works best when product, engineering, finance, risk, and operations share the same goal.

Product needs better checkout outcomes. Engineering needs routing that can be maintained. Finance needs trusted reporting. Risk needs enough data for reviews. Operations needs clear incident handling when a provider has an issue.

What to do next

Start with the problem, then choose the setup.

Define why orchestration is needed
Pick the first success metric
Test failover before launch
Keep routing rules simple
Align reporting with finance
Review reconciliation early
Document who owns changes

Questions to ask internally

What problem should orchestration solve?
Which provider routes perform best by market?
How do we know failover worked?
Can finance trust the reporting?
Who owns routing rules after launch?
Does the added complexity pay for itself?

Guest perspective

Orchestration is useful when it solves a clear business problem.
Routing needs measurement across approval rate, cost, reliability, and operations.
More providers can help, but they also create more rules and more reporting work.
Merchants should keep the setup simple enough for the team to operate.

Listen or watch

Resources

Related episodes

Optimizing Payment Performance with AI: Insights from Inai CEO

Nikita Skitev — Fri, 14 Feb 2025 17:25:41 GMT

Inai joined PAYMENTS FM to talk about payment success rates, AI, routing, testing, and how teams can find payment problems faster.

State of Payments survey

We are launching the State of Payments survey. It takes about four minutes to complete, and anonymous responses are welcome. We will publish the results at the end of the year.

Participate in Survey

Why this matters

Payment performance can look simple in a dashboard and messy in real life. Success rate changes by market, customer segment, provider, payment method, and checkout flow.

AI can help teams spot patterns faster, but the value comes from better decisions. A model should point the team toward a fix, a test, a routing change, or a provider conversation.

Clean data still comes first. If payment events, orders, customer segments, and provider responses are messy, AI will mostly make the mess easier to summarize.

What to watch

Use AI around metrics that already matter to the business.

Success rate by segment
Failed payment patterns
Checkout test results
Provider performance
Routing outcomes
Account to account opportunities
Data quality gaps
Recommendations that led to fixes

What it means for your team

AI payment work needs product, engineering, data, finance, and operations involved early.

Product needs to know which checkout changes help customers. Engineering needs clean event data. Finance needs revenue and cost impact. Operations needs alerts that lead to action. Data teams need definitions that everyone can trust.

What to do next

Start with a few useful questions instead of a big AI program.

Define success rate by business model
Segment before acting on averages
Connect payments to orders and customers
Test checkout and routing changes
Review data quality first
Track actions after recommendations
Keep a human review step

Questions to ask internally

Which payment questions take too long to answer today?
Can we connect payment, checkout, order, and customer data?
Which AI recommendations led to action?
How do we measure if a fix worked?
Which data gaps block useful analysis?

Guest perspective

Payment success rate needs context by customer, market, method, and provider.
AI can help teams find patterns faster when the data is clean.
A/B testing and routing changes need clear measurement before teams scale them.
The practical test is whether AI changes decisions and improves performance.

Listen or watch

Resources

Related episodes

Creating Fintech Success Story in Emerging Markets: The inDrive Approach

Nikita Skitev — Thu, 06 Feb 2025 03:37:36 GMT

Accepting payments in emerging markets has always been a challenge. Enabling local currencies, local payment methods, and staying compliant with local regulations are just some of the problems that businesses face when they operate in these markets.

I always wanted to speak to someone who had already achieved some significant scale and success while operating in these markets. This is why, for today's interview, our guest is Alina Zavorokhina, who is the Head of Product and Business at inDrive Money. If you are not familiar with inDrive, inDrive is a global mobility and urban services platform.

In today's conversation, we'll be taking a deep dive into some specific and unique challenges that inDrive navigates while processing payments across the geographies they operate in. We'll also discuss inDrive’s innovative financial services offerings.

Can you give us a high-level description of what inDrive is and what role payments play in inDrive's success?

I think that actually not so many people know about inDrive, because usually when I travel somewhere, for example, to Europe or the US, everybody asks me, "inDrive? So what is it?" We are a mobility company. We run an app that allows users to hail rides, order courier or cargo deliveries, and we primarily operate in emerging and developing markets. And that's also kind of our mission. We know that in developed countries, there are already so many services, and there is no challenge, you know, just to order a taxi or, for example, order some food. But in developing countries, the challenge lies in how to provide these services to a wider population and do so on equitable terms.

inDrive is originally from a city called Yakutsk, which is the coldest city in the world. The origin story is that one day the temperature dropped to negative 40, and there was actually a problem ordering a regular taxi because taxi operators doubled their prices, and many were stranded in the cold and could not get where they were going. That’s when one of our colleagues, who still works at inDrive, created a social media group to connect people. So, if, for example, you wanted to go somewhere and you had some space in your car, you could pick up this person and go somewhere together. And that's actually how inDrive, with the 48 countries where we operate now, was born.

Regarding payments, that's a super interesting topic. If you order a car with inDrive, you, as a passenger, usually pay directly to your driver. In most cases, inDrive does not handle this transaction. Usually, people pay cash, as we know that cash is still the most used form of payment in many countries where we operate. They can also just transfer money online to the driver's bank account or pay with any popular electronic wallet available in the country. That’s how we can provide freedom to both drivers and passengers, as they actually decide both the price and the method of payment.

You mentioned that inDrive operates in emerging markets. So I would imagine there are lots of interesting challenges. Can you tell me a little bit more about your payment strategy in these markets and what's your recipe for success in accepting payments in all these different countries?

The main challenge is providing the most convenient payment methods for our users, and understanding what those methods will be in all of the countries where we operate and then keeping them stable. We do have a kind of internal wallet, and if you are a driver, you need to top up this wallet in advance to be able to later get some orders from passengers. We, as inDrive, will charge a commission from this wallet at the end of the ride. The commission is not high; usually, we charge just around ten percent, while, for example, our competitors may charge up to 50% of the transaction. And that means also for us that we can't afford a high commission when we pay for payments from providers.

The challenge is finding payment providers that allow us to offer convenient payment methods to drivers while maintaining low commissions. Drivers usually top up their wallets at the beginning of their day. They may have a bank card, but usually, they have cash. That means for us that we also need to provide cash payment methods for them. As a result, we have different payment methods and partners in all of the countries and also manage the commission to keep it at the same 10% level everywhere.

Global payment methods like Visa, MasterCard, and PayPal are all trying to cover as many markets as possible. But local payment methods are also very popular. What trends do you see? Do you see that domestic payment methods are growing even faster?

Definitely, we have different scenarios in different countries, but I think in general we have 30% of transactions made by a bank card like Visa or MasterCard, 30% in cash, and 30% by some local payment methods. But there are some differences. For example, Mexico is one of our biggest markets, but the payment trends there differ from what we see in other LATAM countries. Despite efforts to introduce local payment methods (SPEI, CoDi), they haven't gained significant traction yet. Instead, Mexico seems to be following a similar path to the US, where cards gain popularity. But when we, for example, go to Brazil, there is PIX, which is already a world-known success. They provided the payment rails so that with PIX, you can transfer money instantly from one bank account to another in one second without any additional commission for the people making the transaction. And in Brazil, 90 percent of our drivers top up their wallets with PIX.

So, there are many cases in the world, and definitely, local payment methods are booming, but it also depends on the government strategy and how they help local payment methods grow.

You mentioned that the payment landscape in emerging markets is very fragmented, and you need many providers. Are there any other challenges you're facing when operating in these emerging markets from a payments perspective?

I think stability is also a problem. To ensure payments are consistently available for our drivers without interruptions, we always need strong backup options. For example, last year, we had a big project building backups in different countries for other payment providers and payment methods.

Another thing that we're doing is integrating with payment orchestrators, which help us manage the payment flows between different providers and methods. I may say that it's a real success case for us because we’ve managed to reduce costs significantly while improving the product funnel, leading to a much better user experience and more efficient payment processing overall.

When you talk about the savings opportunity, do you mean mostly on the fees that payment orchestrators allow you to route transactions more efficiently, or do you mean more on the integration side that they can save you hours of work in building integrations with different gateways?

Actually, that's a good question because as of now we calculated only the savings on the cost for the fees, but I like your idea to also calculate the savings on the integration side. I think we did save on the integration because usually, they provide the payment methods included. We still need to, for example, sign contracts with the payment providers, but regarding the integration, it's already included.

You said that inDrive treats drivers as entrepreneurs, and I believe you recently launched a couple of new products for drivers on the fintech side. Can you tell us a little bit more about these products?

Two years ago, we created an internal startup, now called inDrive.Money, and the aim of this team was to find out what kind of financial products we may provide to our millions of users. We found that there are no big challenges among our passengers and there are many other financial products in the market they can use. But there is a huge injustice when we speak about drivers. These are people who work for themselves as gig-economy workers. They choose to spend their time, energy, and car earning money for themselves and their families, and usually, they work with some platforms, and they earn enough. But usually, traditional banks and financial organizations don't know about this income, and even if they do, they don't find it valid and reliable enough to provide any financial services to drivers, such as loans or credits. We spent one month traveling across Latin America, talking with our drivers, and we found how difficult it is for them to get credit when they need it.

When they go to the bank asking for a loan, they get declined, and they need to go to microfinancial organizations that don't decline but provide inadequate interest rates. It's just impossible for them to pay on time, and in the end, they ruin their credit history. That's super sad, listening to these stories.

And what we did was the launch of a new product – cash loans for the drivers. The advantage is that we know how much they earn, and there is no other company in the world that knows that as well as inDrive. We then partner with a financial institution that scores the data and provides the loans, and we enable the whole process for drivers through our inDrive app. That's how we built a credit product customized for them. Drivers loan the exact amount of money with an adequate interest rate so that they can get cash, pay for whatever they want, and then repay the loan by continuing to make rides with us. We not only provide the cash, but we also help them repay the loan on time thanks to seamless integration of repayment into the inDrive app. This is the exact moment when they build their credit history for the future. That's how, in the future, they can get a loan for a car or a bigger amount of money.

We launched this product last year. First, we launched in Mexico, then we scaled to Colombia, and now we have two more countries to launch this year.

So, I would imagine if you're scaling this product, you consider it a success. Do you measure success for this? Is it more about the value you bring to your drivers and increasing the value of your platform, or do you also see this as a revenue opportunity for inDrive?

Actually, both. When we started this project, we were focusing on the users. That's how we found this issue, that's how we found the partner who helped us build this customized product. It was just a test. First, we tested the demand. Then, we found that, first, our drivers love this product. We did NPS surveys, and we know that the probability that they will recommend this product to their friends and colleagues is 75%, which is amazing for a credit product. Second, we know that the drivers who took a loan started making more rides with us, which is exactly the benefit for the main business because that's how we increase loyalty and retention. Drivers trust us, and they see that we trust them too, which makes our connection with them even stronger. And number three, we also earn on that. We earn some revenue share. That's why I would say it's definitely a success because all of the three stakeholders – users, the main ride-hailing business, and us as a financial startup – all have some success here.

Yeah, that's great to hear. You mentioned that you also help drivers repay the loan. So, I would imagine that's how this financial product is integrated with the global inDrive system and platform. Can you tell me a little more about how you actually help them do this, and what's the experience like?

The magic here is that we just added an additional commission for them as a repayment for the loan. As I mentioned, we charge a commission as a fee for using the inDrive app, and now we’ve included an extra, small percentage after the ride is completed specifically for loan repayment. That means that drivers still need to top up the wallet, but then, when the ride is finished, they pay the commission for inDrive and also pay for the loan repayment. In the end, we found that drivers were pretty happy with that. One of the reasons why they said they would recommend this product to their friends and colleagues was the repayment with rides. From their perspective, they don’t need to do anything additional to repay the loan. For them, it's all about convenience and building their credit history, as people in Mexico, for example, understand how important that is for their future.

What are your expansion plans with this product? You mentioned that you are in several countries right now. Are you planning to expand to other countries where you operate, or are you planning to add new features to this product?

We plan to scale to more countries. I think this year we will end up in four countries, and during the next year, we plan to launch in an extra four to six countries. That takes time. Every country has a legal scheme that we need to research. An additional integration is sometimes required if we work with a new partner there.

We definitely want to test more ideas about this credit product and repayment with rides. It looks like there is a huge need for credit products among people working in the gig economy, and this repayment with rides is a super convenient method of payment. We also consider some tests with passengers.

When you said the product for riders, do you mean financing for their rides, like "buy now, pay later," or do you mean just if they need to buy something outside of the platform and there will be some sort of financing?

I think we will explore and test different options. Riders trust inDrive, and that's a really nice opportunity for us to test what kind of financial products we can provide to them. Regarding "buy now, pay later" or "ride now, pay later," there's a nice case in India. There's a taxi company called Ola, and they have this "ride now, pay later" feature. Based on comments in the market, that's a pretty interesting idea. I know that Uber also launched this "ride now, pay later" feature in Europe. That's something we want to test first.

Let's talk about the future of payments for inDrive and the future of fintech products. How do you see payments evolving in the next three to five years? Do you see it more on the expansion side, or are you planning any new features on your product for customers?

I think we will discover some methods for how we can still provide online payments for passengers. If we want to gain a new audience, we need to solve this issue with the costs and the convenience of payments.

One idea we have is to keep this convenience of payment directly to drivers but simplify the user experience. For example, enable drivers to suggest the payment methods they want to get payments from passengers. For passengers, automatically provide drivers’ credentials for quick payment through bank services – usually, it's a phone number or a special code when we talk about PIX in Brazil. Another option is payment links. Whatever it is, it is still about connecting passengers and drivers directly, keeping the costs as low as we can, and making the payment process a bit simpler for riders.

Why Some Subscription Merchants Choosing Standalone Billing When There is Stripe Billing

Nikita Skitev — Mon, 27 Jan 2025 04:36:49 GMT

The payments industry is more competitive than ever, with merchants taking advantage of the many providers available to get better deals. For payment providers relying only on transaction fees is not enough – they need to offer more services to keep growing.

Stripe has turned itself into the “Amazon of payments” by adding extra services like Connect, Radar, Taxes, Billing, Treasury, Atlas, Issuing, and others. These tools help merchants handle their payments and business needs all in one place.

When was introduced, Stripe Billing was seen as missing some features, but it has improved into a strong solution that now competes with established platforms like Chargebee and Recurly.

Stripe has even created tools to make it easier for businesses to switch from other billing systems.

Stripe Billing vs Competitors

But why haven’t all merchants switched to Stripe Billing? The answer is payment orchestration.

Standalone billing platforms like Zuora, Chargebee, and Recurly, traditionally have payment orchestration modules. This modules allow merchants to use multiple payment providers and optimize transaction success based on routing strategies like geography, currency, volume, card type or others.

Stripe’s answer to this challenge is the Forward API, the tool that lets merchants use Stripe as a vault while sending transactions to other providers like Adyen, Braintree or others.

So what is a blocker?

While Forward API sounds great, it is currently supports only card payments. PayPal is one of the most popular payment methods in the US and they do not let third-party providers, including Stripe, to process PayPal or Venmo payments for US merchants. To accept PayPal, merchants have to work directly with PayPal through PPCP or Braintree.

This forces merchants to make a choice:

Use Stripe Billing and Forward API for card payments, without accepting PayPal
Use a 3rd party billing system and manage multiple vendors
Build own billing solution

What’s next

Stripe is heavily investing in improving the Forward API to handle more payment types, better integrations, and additional providers. Stripe also trying to turn the table by introducing its own proprietary wallet, Stripe Link (see my LI post).

If PayPal opens up its system or Stripe finds a solution, it could significantly boost Stripe’s Billing growth.

For merchants, the takeaway is clear: build a payments strategy that balances your business needs and customer experience while considering the strengths and limitations of each platform.

PAYMENTS FM

Building a Payments Business For Your Software Platform: Emi Keshler, Payabli

What a successful payments program means to you?

How to succeed with merchant onboarding

What it means for your team

What to do next

Questions to ask internally

Related episodes

ACH credits get earlier morning availability, and more

News of the week

ACH credits should be available earlier in the morning

Other news

Card network and fraud updates

ACH, account-to-account, and instant payments

Merchant operations and payment performance

Agentic commerce, stablecoins, and cross-border

Payments Substack posts

More from Payments FM

The Business of Payments for Software Platforms with Jo Phillips & Will Corbera, Payabli

Why this matters

What to watch

What it means for your team

What to do next

Questions to ask internally

Guest perspective

Resources

Related episodes

Subscribe

Processing payments for insurance industry

Request your numbers

Provide relevant payment methods

Different sales flows require different payment setups

A failed payment means no coverage

Renewal payments are harder than they look

The regulatory layer

Next steps

ACH Recovery Framework

What this guide covers

The framework

1. Authorize transaction

2. Verify bank account

3. Classify refusal codes

4. Retry payments

5. Adjust billing logic

6. Monitor results

Bottom line

Demystifying Open Banking and Pay-by-Bank with Anubhav Pradhan, ShiftMate

Why this matters

What to watch

What it means for your team

What to do next

Questions to ask internally

Guest perspective

Listen or watch

Resources

Related episodes

Subscribe

Who is a Payments Product Manager?

Product Manager VS Payments Manager

Payments PM role in large companies

Payments PM role in startups

What are the payments PM skills?

Payments expertise

Soft skills

Bottom line

Payments Education

Payments Interviews

How AI Analytics Transforming E-Commerce Businesses with Andrei Rebrov, Finsi

State of Payments survey

Why this matters

What to watch

What it means for your team

What to do next

Questions to ask internally

Guest perspective

Listen or watch

Resources

Related episodes

Subscribe

Agentic Commerce with Colin Luce, CEO Basis Theory