What buyers ask AI before choosing a fintech startup

Before they look at your product, buyers ask an assistant whether you are allowed to do what you say, what you charge, and how long the integration will take. Product features come fourth, and by then most shortlists are already formed.

The companion page on how a fintech startup gets recommended by AI covers what to change on your site. This page is the question list itself.

The questions, in the words buyers use

The allowed to do it questions

• "Is X an RBI authorised payment aggregator"
• "Can a company do Aadhaar based KYC without being a bank"
• "Which account aggregators are live in India"
• "Do I need my own NBFC licence to offer credit in my app"
• "Is it legal to store card numbers, what is tokenisation"

The money questions

• "What is the usual charge for UPI, cards and net banking in India"
• "Cheapest payment gateway for a small business"
• "Is there a setup fee or an annual maintenance charge"
• "How long until money reaches my bank account"
• "Who bears the cost of a chargeback"

The build questions

• "How many days to integrate a payment gateway in a hosted or custom checkout"
• "Does it have a sandbox and test credentials"
• "Which SDKs are supported"
• "How do webhooks handle a retry, and are they idempotent"
• "Can I reconcile settlements against an automated report"

The trust questions

• "Is X reliable, has it had outages"
• "Who are its biggest customers"
• "Is my money safe if the company shuts down"
• "Where is my customers' data stored"

What a good answer looks like

A good answer is one page per question, with the answer in the first line and the proof under it. For a pricing question that means a rate list with a date. For a compliance question it means the entity name, the authorisation type and a link to the register you appear on. For a build question it means a number of steps and a realistic time, written by whoever actually does the integrations.

The test is simple. Could an assistant quote one sentence from your page and be correct? If the sentence it would have to quote is "flexible pricing to suit your business", you have written nothing it can use.

For the settlement question, the good answer separates three things that buyers confuse: when the transaction succeeds, when the money leaves the aggregator, and when it lands in the merchant's account. Say which day each happens on, what a bank holiday does to it, and what a refund or a dispute does to it.

Where you are probably missing

Fintech sites are usually strong on product pages and weak in exactly the places buyers ask about.

• No public pricing. A contact form where a rate card should be.
• Compliance shown as badges, not as text a crawler can read.
• No status or reliability page, so the uptime question gets answered by whoever complained loudest on a forum.
• No comparison pages, so the "alternative to" question is answered entirely by other people's blog posts.
• Docs closed behind a login. If your documentation needs an account, it does not exist as far as an assistant is concerned.
• No page on data storage and incident reporting, although every enterprise buyer asks and the answer is short.

A worked example: the integration time answer

Buyers ask how long integration takes, and almost every fintech answers "quick and easy", which no assistant can repeat. Here is a complete answer instead.

Split it by path. For a hosted checkout on a common storefront platform, list the steps: create the account, complete onboarding and document submission, get test credentials, install the plugin, run a test transaction, submit for activation, go live. For a custom server side integration, list the steps again: sandbox keys, order creation call, checkout handoff, webhook endpoint with signature verification, idempotency handling, refund flow, reconciliation report. Give a realistic working day range for each path, and name the step that usually causes the delay, which in India is almost always onboarding documentation rather than code.

Then add the onboarding document list: certificate of incorporation, PAN of the entity, GST registration, bank account proof, the website or app URL with a live policy page, the signatory's identity documents, and a board resolution or authorisation letter where the signatory is not a director. Buyers copy that list straight into a task for their finance team, which is exactly the sort of page that gets cited and shared.

What these questions do not include

They do not include your funding round, your investor names or your team's previous employers. Those matter to hiring and they do not appear in a buying question. They also do not include your product's interface, because a buyer cannot judge it from an assistant's answer and does not ask.

And they do not include anything you cannot substantiate. Do not publish a success rate on transactions unless you measure it and can say over what period and on which instrument. An unsourced success rate is the fastest way to make the checkable parts of your page look unreliable.

What to publish first

Six pages, in this order, and none of them needs a designer.

• Pricing, with numbers and a date.
• Licences and authorisations, in text, with entity names and the register link.
• Integration time and steps, with the onboarding document list.
• Settlement and refund timing, day by day.
• Security, data handling and where data is stored.
• One honest comparison page against the tool you lose to most often.

Then go back to the question list above and write one page for each question you cannot already answer in a single sentence. That list, not a content calendar, is the plan.

Common questions

Which of these questions should we answer first?

Pricing, because it is the most asked and the least answered in this sector. Compliance is a close second but it is a single page. Pricing is the one where your silence actively sends the buyer to a comparison article that ranks you by guesswork.

Will publishing pricing hurt us in negotiation?

Publishing bands does not remove your negotiating room, because the bands themselves contain the room. What it removes is the enquiry from a buyer whose volume was never going to fit, and the comparison article that invented your rate. If your rate is genuinely higher than the market, the page to write is the one explaining what the difference buys.

Our biggest customers are under NDA. How do we answer the customers question?

Describe the shape rather than the names: the sectors you serve, the size range of merchants, the transaction types, and how long your longest running integrations have been live. That is quotable and it breaks no agreement. Never name a customer you do not have written permission to name.

Is a status page worth building for a small team?

Yes, and it does not need to be fancy. A page that states current availability, a dated log of past incidents and what you changed after each one answers the reliability question with evidence. The alternative is that the question gets answered by a merchant's angry post, which is the only public record that exists today.

We sell to banks, not to merchants. Do these questions change?

The compliance and security questions get heavier and the pricing question gets quieter, because bank pricing is always negotiated. Add two pages: one on your security posture in the detail a vendor risk team asks for, and one on your deployment options, including whether you can run inside the bank's own environment. The rest of the list still applies.

What to do first

Pick the five questions above that your sales team answers most often on calls. Write one page for each, with the answer in the opening line, and put the date at the bottom. That is a week of work and it covers most of what a buyer asks an assistant before they ever reach you.