A seller on your platform who needs money between orders will look for it. Ensuring they can find it without leaving your platform is the problem an embedded lending API is built to solve.
It connects your platform to a licensed lender’s systems, so a seller can request working capital, receive a decision, and have money in their account without going elsewhere. A regulated lender does the actual lending. The API puts that product where sellers already manage their orders.
Key Takeaways
- Where the seller has consented, the platform sends their transaction data to the lender’s system. The lender uses it to generate an eligibility assessment or preliminary offer.
- The seller expresses interest in the preliminary offer and completes any required identity checks. The lender runs underwriting and, on approval, provides the seller with the final terms and a Key Fact Statement inside the platform.
- The seller reviews the final terms, accepts, and signs. The lender then disburses directly to their bank account; the platform’s account doesn’t sit in the middle.
- Status updates flow back to the platform through the same API connection, keeping the seller’s loan state visible throughout.
- Two integration routes: a co-branded option with no platform-side engineering build, live in about days; a fully native white-label option using REST API and webhooks, around a few weeks.
What an Embedded Lending API Actually Connects
Two systems that would otherwise sit apart: your platform, where sellers operate every day, and the lender’s systems, where underwriting, KYC, loan documentation, and disbursement happen. The API connects them.
Where a seller has given prior, explicit consent for their platform data to be shared with the lender, the platform sends that transaction history to the lending system. The lending system uses it to produce an eligibility assessment or preliminary offer. That preliminary offer is not a loan approval. Final approval is a separate step, one that follows the seller completing any required verification and formally accepting the offer. Once that sequence is complete, the money reaches the seller’s bank account and status comes back to your platform.
The result is that the seller handles the whole process inside the platform they’re already using.
Who lends the money and what the platform’s regulatory position looks like in this arrangement is covered in Can a B2B Marketplace Offer Loans to Its Sellers Without an NBFC Licence? This article focuses on the API exchange itself.
How a Revolving Credit Line Looks to the Seller
The following is an illustrative example of how a revolving credit line works in this kind of integration, based on the seller journey GLAAS documents for this product type. Specific steps, timelines, and required seller actions vary by product, lender, and integration setup.
A seller logs into their dashboard on the platform. A preliminary credit offer is already visible, based on an eligibility assessment run against their transaction history. This isn’t a loan approval; it shows the seller they’re likely eligible and gives them a sense of the available limit.
The seller expresses interest. They see the lender’s identity and the preliminary loan terms before doing anything further. They’re then asked to complete identity verification, which may involve reviewing pre-filled details or providing additional information. This runs through GLAAS’s systems via the API; the platform team doesn’t handle or process it.
Once verification is complete, the seller receives the final approved terms and a Key Fact Statement summarising the loan. They formally accept, e-sign the loan documents, and choose how much to draw and on which repayment plan.
Money arrives in their bank account from the lender. Repayments run over the agreed schedule, managed through the lender’s systems. As they repay, the available limit refreshes for the next draw.
What the Platform Sends, and What Comes Back
The central input the platform provides is the seller’s transaction history: GMV over time, how often they transact, their settlement patterns, how long they’ve been active. This is data the lending system doesn’t have independently, shared subject to the seller’s prior consent.
A bureau score reflects a seller’s borrowing history. Platform transaction data can help the lender assess how that business actually operates today. Incorporating this alongside bureau and other checks can produce a more relevant view of a seller’s credit profile than bureau data alone, though how much weight it carries is a function of the lender’s underwriting policy. Pricing may also reflect that data, depending on how the lender has configured its model for the platform.
What the API carries back:
- A preliminary eligibility result, used to populate an offer visible in the seller’s dashboard.
- The lender’s credit decision and final approved terms, along with a Key Fact Statement, once the seller has completed verification.
- Status confirmation once the seller accepts and signs.
- Status updates as the loan moves through disbursal and repayment.
Separately, the platform’s operations team has access to a portfolio dashboard: a real-time view of active loans, repayment rates, and early signals on the book. This is a different interface from the per-seller API responses that drive the seller’s journey through the product.
The platform team doesn’t build the credit model or manage individual accounts. That sits with the lender and its systems.
The Lender’s Role: Offer, Approval, and Disbursal
The offer appears inside the platform’s product, under the platform’s brand or co-branded depending on the integration route. Before the seller accepts anything, they see the lender’s identity and the key loan terms, along with a Key Fact Statement.
Funds flow directly from the licensed lender to the seller’s bank account. Under RBI’s NBFC Credit Facilities Directions, 2025, disbursement must move from the regulated entity to the borrower, not through the platform’s account. Where a co-lending arrangement is in place, the loan documents identify the applicable lenders and their respective roles. The loan agreement is with the lender or co-lenders identified in the loan documents, never the platform.
Whether the platform carries any first-loss exposure depends on its specific role in the arrangement, applicable regulatory limits, and the terms of the agreement it has signed. This involves regulatory requirements and the platform’s eligibility to take that position, not just a commercial negotiation.
Post-disbursal, collections, repayment tracking, and loan servicing are managed by GLAAS on behalf of the lending partner. The platform team doesn’t run that operation.
What Your Platform Needs to Build
How much your team builds, and how long it takes, depends on which route you choose. The distinction matters: the native route requires the platform to integrate with GLAAS’s API; the no-code route uses GLAAS’s infrastructure without any platform-side API build.
Co-branded, no-code
There’s no platform-side engineering build under this route. The provider sets up the seller-facing journey, which runs within the platform’s product with no redirects to an external site. The experience carries a “Powered by GLAAS” co-brand mark. Setup and operational coordination between the platform and the provider still happen before launch, but the platform’s technical team doesn’t build or integrate anything. KYC, loan documentation, servicing, and collections are handled on the provider’s side. A platform can be live in under 2 days under this route.
Fully native (white-label)
The platform connects using the provider’s REST API and webhooks. SDK options are available for iOS, Android, and web. Integration starts in a dedicated sandbox environment; the platform tests the full seller journey before moving to production. Under this route, the seller sees only the platform’s own brand and UX throughout. Going live takes under 2 weeks.
In both cases, the provider manages the underwriting model, KYC workflows, loan documentation, disbursement, collections, and post-loan servicing. The platform’s team doesn’t build or staff any of that.
The choice between routes comes down to speed versus control over the seller-facing interface. The no-code option gets credit in front of sellers faster. The native route takes longer but gives the platform full ownership of how the product appears to sellers.
Choosing the Right Integration Route
The API turns a licensing arrangement into something a seller can actually use. It carries the seller’s transaction data to the lender’s systems, surfaces the decision and offer in the seller’s dashboard, and carries status updates back to the platform. The lender handles disbursement directly to the seller’s bank account, typically within hours of approval.
Platforms like Razorpay and Meesho have built this into their merchant products. If you want to see what it would look like on your own platform, contact us and we’ll map which route fits your current setup.
Frequently Asked Questions
1. Does the platform need its own lending licence to use an embedded lending API?
No. The licensed NBFC or co-lending partner handles the lending. The platform operates under that arrangement without needing its own licence or balance sheet.
2. Does the seller stay inside the platform throughout?
Yes, under both routes. The co-branded journey runs within the platform’s product with a “Powered by GLAAS” mark. The native integration shows only the platform’s own brand and UX. There are no redirects to an external site in either case.
3. What platform data is used for underwriting?
The credit rule engine incorporates the platform’s own transaction data where available and with the seller’s consent: GMV history, settlement patterns, order frequency, and how long the seller has been active. This feeds the underwriting model alongside bureau data. How it is weighted in the final decision depends on the lender’s underwriting policy and the platform’s specific setup.
4. What does GLAAS do and how is it regulated?
GLAAS provides the embedded lending API and the credit technology behind it: underwriting systems, KYC workflows, collection management, and loan lifecycle monitoring. The licensed lender in each arrangement, which may be Gromor Finance or a co-lending partner, is the regulated entity that underwrites and disburses. GLAAS has disbursed ₹1,500 Cr+ across 110,000 loans to 13,000+ MSME borrowers, with seven in ten borrowers returning for another loan.
