SaaS onboarding for funding partnerships gets over-engineered. Someone books a “technical kickoff” for an API that is not the product. The product is: partner approval, a unique ref code, a branded or co-branded apply URL, a dashboard, ACH details, and copy review. If your engineers are waiting on OpenAPI specs for live decisioning, they are waiting on something Loanable does not ship as a public REST lending API.
Loanable matches users to 150+ lenders. You send them through your unique partner link. You are not the lender. Funded deals pay 50/50 of Loanable profit, Monday ACH, no minimum. Onboarding is successful when a test click in production still shows an application on your dashboard.
A practical implementation sequence
Get approved as a partner. Store the code in config. Put the button behind a feature flag. QA query-string survival on iOS and Android webviews. Review CTA copy with whoever owns compliance tone. Train support. Enable the flag for a slice of users who actually have a cash-gap screen. Watch the dashboard before you announce it in a changelog as “in-app lending.”
- Separate production and sandbox-style test codes if you will click around
- Document the exact URL, including optional type=
- Assign an owner for Monday ACH reconciliation
- Write the “we are not the lender” sentence into the help center first
What “go live” is not
It is not a press release that you launched a bank. It is not a widget that shows a live offer amount. It is not piping customer bank logins through your servers into a mystery underwriter. It is a tracked apply flow. Working capital may fund as soon as 24 hours after a complete file; your changelog should not say you fund payroll overnight.
Expansion after the first button
Once attribution works, add product-specific deep links where the UI context is clear. Equipment screens can hint equipment. SBA-ish expansion stories can hint SBA. The 50/50 split does not change, including on large facilities up to $50M. Your onboarding metric is still “code survived the click,” not “we listed every product in the hamburger menu.”
Kill criteria for the feature flag
If production clicks do not create dashboard starts for a week, roll the flag back. Do not “keep it on for awareness.” You are training users that the button does nothing, or you are leaking unattributed traffic. Debug the webview. Then reopen. Loanable matching 150+ lenders cannot begin without an application that still has your code.
Write the kill criteria before launch so growth cannot override them in the war room. Include a check that Monday ACH details are on file even if you expect no fundings yet. 50/50 with no minimum is cold comfort if the first funded file hits a rejected ACH. unique partner link onboarding is configuration plus that bank profile, not a sprint named Platform Lending API.
Put the production URL in your runbook next to other billing keys, including which environment the code belongs to. When an intern rotates, they should not have to Slack a founder for the ref. Loanable will still match 150+ lenders. You will still earn 50/50 of profit on attributed fundings, Monday ACH, no minimum. Onboarding fails when the code lives in one laptop. Embedded solutions are an unique partner link flow plus that operational hygiene.
Onboard the partnership you actually have. Start with Loanable embedded solutions and ship unique partner link with a dashboard check before you staff a fake lending platform team.