GLAAS Blog

Tag: Lending API

  • What Is Embedded Credit Infrastructure, and How Is It Different From a Lending API?

    What Is Embedded Credit Infrastructure, and How Is It Different From a Lending API?

    Embedded credit ≠ Lending API.  Some providers use these two terms interchangeably. They don’t mean the same thing.

    A lending API is the connection between your platform and a lender’s system. Embedded credit infrastructure is everything required to run a credit product around that connection.

    That distinction comes down to 4 things: who decides which merchants qualify, what credit product they receive, who the licensed lender is, and who manages the merchant journey after disbursement.

    Merchants on B2B platforms need working capital between orders. When a platform doesn’t offer it, they find it elsewhere. That outside financial relationship gradually pulls engagement away. The distinction between a lending API and embedded credit infrastructure determines how much of that credit product a platform actually controls.

    Key Takeaways

    • A lending API is a data connection between your platform and a lender’s system. It sends application data and returns a result.
    • Embedded credit infrastructure is the broader setup around that connection. It can cover underwriting, product configuration, a licensed lending entity, the merchant-facing experience, and what happens after disbursement.
    • The practical difference is who handles what: who makes the credit decision, who sets the product terms, where the merchant applies and repays, and who manages collections.
    • The word “API” describes a connection method, nothing more. It tells you nothing about how the provider underwrites, what product they offer, or what happens once a loan is disbursed.

    What Does a Lending API Do?

    A lending API is a software connection between your platform and a lender’s loan origination system. When a merchant applies for credit, your platform sends their application data through the API. The lender’s system processes it and returns a result: approved, declined, or flagged for manual review.

    Data moves between the two systems without the platform needing to build its own origination system. The API doesn’t determine how the lender makes the credit decision, what product they offer, where the merchant completes the application, or who handles collections after disbursement. Those depend on the lender or provider, and they vary significantly from one provider to the next.

    Some platforms find this sufficient when the goal is connecting merchants to external funding. Others need more control over underwriting, product design, merchant experience, or post-disbursement operations.

    What Does Embedded Credit Infrastructure Actually Add?

    Embedded credit infrastructure is the assembled setup that lets a platform offer credit as a native product, without building an underwriting team, holding a balance sheet, or applying for a lending licence.

    The API is one component. 4 decisions determine everything else: who underwrites, what product gets offered, who the licensed lender is, and who manages repayment. Here’s what each one involves.

    1. Who Decides Which Merchants Qualify?

    In a properly built embedded model, the underwriting engine can incorporate transaction data from the platform itself: a merchant’s order volumes, payment behaviour, months of active trading, average basket size. If a merchant has bought and paid reliably on your platform for two years, that trading history is useful credit information even if their bureau file is thin.

    Bureau data and platform data work together rather than replacing each other. For platforms where many merchants are first-time formal borrowers, the ability to incorporate platform signals changes who qualifies.

    2. What Credit Product Can be Offered?

    A textile marketplace and a pharmaceutical distributor have different cash-flow cycles and very different borrowing needs. A configurable product setup means loan amounts, tenors, and repayment structures can be set to match the platform’s specific merchant base, rather than applying one standard product across all borrowers.

    3. Who Actually Lends the Money?

    Credit disbursement in India requires a licensed bank or RBI-registered NBFC to release funds. In a full embedded setup, the licensed lender is already part of the arrangement, either as an entity the provider owns or through a partnered bank or NBFC. The platform does not need to become a lender itself.

    4. Who Manages the Merchant Journey and Repayment?

      In an embedded setup, the merchant’s experience, from application through repayment, can stay inside the platform. Collections, repayment tracking, and delinquency monitoring are the provider’s responsibility. The platform gets visibility through a dashboard rather than inheriting the operational load.

      Embedded Credit Infrastructure vs a Lending API: How The Two Compare

      Standard API arrangementFull Embedded Credit Setup
      Credit decisionUsually controlled by the lenderCan incorporate platform data and configurable underwriting
      Credit productOften lender-ledCan be configured around the platform’s merchant base
      Merchant experienceMay redirect or use a co-branded flowCan remain inside the platform
      Licensed lenderMay need a separate lender relationshipIncluded in the overall setup
      Post-disbursementUsually lender-ledCan include platform visibility, monitoring and lifecycle support

      Why the Difference Matters in Practice

      Embedded Credit vs Lending API

      Approval Coverage

      A lender that relies heavily on bureau data may struggle to assess merchants with limited formal borrowing history, even if those merchants have traded reliably on your platform for years. An underwriting model that incorporates platform signals changes who qualifies.

      Merchant Experience

      Under a standard API arrangement, the merchant is redirected to the lender’s interface to complete the application and manage repayment. Under a fully embedded setup, the merchant can complete the credit journey without leaving your platform, while the regulated lending remains with the licensed lender.

      Product Fit

      A working capital loan structured for a twelve-week textile sourcing cycle won’t serve a dealer who needs a six-month equipment financing arrangement. Configurable product terms, set in collaboration with the provider, mean the credit product fits how the platform’s merchants actually trade.

      Visibility After Disbursement

      Under a standard API setup, collections belong to the lender and the platform has limited sight of which merchants are struggling until it shows up in their trading behaviour. A full embedded setup can also give the platform ongoing visibility through portfolio dashboards, repayment monitoring and early-warning signals on at-risk accounts.

      For more on how the regulatory side of embedded credit works for platforms, see our piece on finding the right lending partner for embedded finance. 

      How GLAAS is Set Up

      Here’s how GLAAS’s model works.

      • Credit decision: GLAAS’s underwriting engine incorporates platform transaction data alongside bureau data, helping assess merchants with limited formal borrowing history using a broader set of signals.
      • Credit product: GLAAS offers 25+ configurable credit products. Loan amounts, tenors, and repayment structures can be tuned to a platform’s merchant base rather than applied uniformly.
      • Merchant experience: GLAAS supports white-label and native journeys so merchants apply and repay without leaving the platform.
      • Licensed lender: GLAAS operates through Gromor Finance, its RBI-licensed NBFC. Platforms integrating with GLAAS don’t need their own lending licence or capital commitment.
      • Post-disbursement: Collections, repayment monitoring, and portfolio reporting run through GLAAS, with live dashboard access for the platform.

      GLAAS has funded 110,000 loans to 13,000+ MSMEs served across India. Seven in ten return for another loan. A co-branded setup goes live in under 2 days; a fully native integration in under 2 weeks.

      Evaluating how to add credit to your platform? Talk to GLAAS →

      Frequently asked questions

      1. Is a lending API the same as embedded credit?

      No. A lending API is a data connection: it sends a merchant’s application to a lender and returns a result. Embedded credit is the broader setup around that connection, covering underwriting, product configuration, the merchant journey, and what runs after disbursement. The API is one component inside a full embedded credit setup.

      2. Does a platform need its own NBFC licence to offer credit to its merchants?

      No. In an embedded model, the platform facilitates access to credit; it doesn’t lend. Lending is done by a licensed bank or RBI-registered NBFC that is part of, or partnered with, the provider. GLAAS operates through Gromor Finance, its own licensed NBFC, so platforms integrating with GLAAS don’t need to source a lender separately.

      3. How does platform transaction data improve credit decisions?

      Bureau data reflects a merchant’s formal borrowing history. Platform data reflects how they actually trade: order volumes, payment reliability, months of active trading. For merchants with thin bureau files who trade reliably on a digital platform, incorporating platform data can change whether they qualify.

      4. What happens to collections and repayments under an embedded credit model?

      The licensed lending entity manages collections. In a full embedded setup, the provider can also run post-disbursement monitoring, repayment tracking, and early warning on at-risk accounts. The platform has visibility through a dashboard but doesn’t run the collections operation.

      5. What does GLAAS provide, and who is the regulated entity?

      GLAAS is an embedded credit infrastructure provider for B2B digital platforms in India. It brings underwriting technology that incorporates platform transaction data, 25+ configurable credit products, a merchant experience that can stay inside the platform, and lifecycle management after disbursement. The regulated lending entity is Gromor Finance, an RBI-licensed NBFC owned and operated by GLAAS.

    1. How Does an Embedded Lending API Work for a B2B Platform in India?

      How Does an Embedded Lending API Work for a B2B Platform in India?

      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

      How Does Underwriting Work Without the Platform Doing Any of It

      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.