Embedded vs hosted credit is a data decision, not a UX one

Teams pick embedded because they want their branding on the flow. That is a real reason. It is also the second question, not the first.

The first question is where the credit data goes.

In a hosted workflow, the consumer submits directly to the provider. The provider runs the pull and displays the result. Your system may receive an outcome, but the raw input and the credit response stay in their infrastructure.

In an embedded workflow, the consumer submits to you. Your backend calls the provider and receives the credit data. That data now lives in your systems, with the storage, retention, and access-control obligations that follow.

So choosing embedded for branding also means choosing to hold consumer report data. Plenty of teams make that call without realizing they made it, and it surfaces during compliance review after the build is finished and the design approved.

A related point that catches people. Vendor naming is inconsistent. Some call an iframe embedded because it renders inside your page, but functionally it behaves like hosted, since the provider serves and controls what happens in the frame. Ask where the form is actually served from rather than trusting the label.

And regardless of model, the credit call belongs on your server. Credentials and credit data in client-side code are visible to anyone who opens developer tools.

The useful sequence is to decide on data and compliance grounds first, then design within whichever model you chose. Some teams launch hosted and move to embedded once volume justifies it, which works cleanly if the provider supports both.

CRS offers direct API access as well as white-labeled delivery, so the data layer can stay constant even when the front end changes.

Which model did you land on, and would you choose the same again? Curious whether the compliance side changed anyone's mind.