Last updated: August 2026
The choice looks like a UX decision and is really a data decision. Where the credit interaction happens determines who holds the data and who captures consent. It also determines who carries the obligation.
Key takeaways
- An embedded credit workflow runs inside your product. A hosted one moves the consumer to the provider’s page.
- The difference determines where consumer consent is captured and who is responsible for capturing it correctly.
- Hosted workflows shift disclosure responsibility to the provider, which reduces your build and your control.
- Embedded workflows keep the consumer in your experience, and put the compliance surface in your product.
What each workflow means
An embedded credit workflow runs the credit interaction inside your own product. The consumer fills out your form, sees your branding, and gets the result without leaving. A hosted workflow sends the consumer to a page the provider controls, either by redirect or inside an iframe.
A third option sits alongside both. An API-only build gives you raw data access and you construct the entire interface yourself. It offers the most control and carries the most responsibility.
The naming is inconsistent across vendors. Some call an iframe embedded because it appears inside your page. Functionally it behaves like a hosted page, because the provider controls what happens inside the frame. Ask where the form is actually served from rather than what it is called.
Where the credit data actually travels
This is the distinction that matters and the one vendor material usually skips.
In a hosted workflow, the consumer submits their information directly to the provider. The provider runs the credit pull and displays the result. Your system may receive an outcome. The consumer’s raw input and the credit response pass through the provider’s infrastructure.
In an embedded workflow, the consumer submits to you. Your backend calls the provider, receives the credit data, and decides what to display. The credit data lands in your systems.
That second path means your infrastructure handles consumer report data. Storage, retention, and access-control obligations follow. Teams choosing embedded for branding reasons sometimes do not realize they have also chosen to hold regulated data.
The corollary is worth stating: the credit call belongs on your server, never in browser code. Credentials and credit data in client-side JavaScript are exposed to anyone who opens developer tools.
Who holds which obligation
| Embedded | Hosted | |
|---|---|---|
| Where the form is served | Your product | Provider’s page or iframe |
| Who captures consent | You | Provider |
| Who controls disclosure placement | You | Provider |
| Whose systems hold credit data | Yours | Provider’s |
| Branding control | Substantial | Styling only |
| Engineering effort | Moderate | Minimal |
| Where a compliance failure surfaces | Your product | Provider’s page |
The consent row is the one to read carefully. In a hosted workflow the provider has built and tested that disclosure across many customers. In an embedded workflow you own it, which means you also own getting it wrong.
How to choose between them
Three questions usually settle it.
How much does the handoff cost you? If your funnel loses meaningful volume at the redirect, embedded pays for itself. If your consumers are already committed by that point, hosted is fine.
Do you have somewhere to put the compliance surface? Embedded means owning the disclosure, the consent flow, and the decline messaging. That needs a product team with compliance access, not just a designer.
Do you want to hold consumer report data? Some teams actively prefer not to. Keeping regulated data out of your infrastructure simplifies audits, retention policy, and access review.
There is a middle path worth knowing about. Some teams run hosted for the initial launch and move to embedded once volume justifies it. The credit provider stays the same, so the migration is a front-end change rather than a new vendor relationship.
The mistake worth avoiding
Choosing embedded for branding, then discovering the compliance obligations afterward, is the most common failure pattern here.
It usually surfaces at a predictable point. The build is done and the design approved. Then compliance review asks where consent appears and how retention is handled. The answers require rework to a flow that is already finished.
Deciding the model on data and compliance grounds first, then designing within it, avoids the rebuild. The branding question is real, but it is the second question, not the first.
For design considerations within either model, see customizing embedded credit UX.
How CRS supports both models
CRS supports embedded, hosted, and API-only deployments through the same integration and the same data. Teams are not locked into a model at the vendor level. Moving from hosted to embedded later does not mean changing providers.
For embedded builds, the credit data API returns tri-bureau credit plus identity, fraud, and public records in one request. Everything arrives in the CRS Standard Format. Responses return in under two seconds on average, with 99.9% uptime. Developers get sample code in nine languages plus a self-serve sandbox.
For hosted and white-labeled delivery, prescreen and offer presentation run under your brand. Self-serve configuration means no engineering is required to adjust thresholds or rules.
CRS is a licensed consumer reporting agency recognized by all three national bureaus. It guides FCRA vetting during onboarding regardless of which model you choose. See the guide to embedding credit checks into your website.
Frequently asked questions
What is an embedded credit workflow?
An embedded credit workflow runs the credit interaction inside your own product. The consumer completes your form and sees the result without leaving your site. Your systems handle the credit data and the consent capture.
What is a hosted credit workflow?
A hosted credit workflow sends the consumer to a page the provider controls, by redirect or iframe. The provider captures consent, runs the credit pull, and displays the result. Your systems may receive only an outcome.
Is an iframe embedded or hosted?
Functionally hosted. The frame appears inside your page, but the provider serves and controls what happens within it. Ask where the form is actually served from rather than relying on the vendor’s label.
Which model is better for compliance?
Neither is inherently better. Hosted shifts consent capture and disclosure placement to the provider, reducing your responsibility and your control. Embedded gives you control and the obligation that comes with it.
Can you switch from hosted to embedded later?
Yes, if your provider supports both. The migration is a front-end change rather than a new vendor relationship. Some teams launch hosted and move to embedded once volume justifies the build.
