White-Label Partner
Setting up your platform
Everything required to take your White-Label tenant from empty to live — domains, email, branding, payments, and the checks that confirm it actually works. Work through it in order. Each step assumes the one before it is done.
How to use this page
You do not need to understand DNS, SMTP, or SSL to finish this. Each step tells you exactly where to click and exactly what to type. Where a provider does not publish enough detail for us to be certain, we say so and ask for a screenshot rather than guess — a wrong DNS record is harder to unpick than an unmade one.
Nothing here asks you to send us a password, app password, secret key, or API credential. Every credential is entered directly into your own portal. If anyone asks you to send one, including someone claiming to be us, stop and call.
Step one
Gather this before you touch anything
Most stalled setups stall here — halfway through a DNS change, waiting on account access or permissions. Collecting these items first prevents most setup delays.
Your root domain
The domain the portals will live under, for example yourcompany.com.
Your Partner Portal Domain
Where you and your team sign in. Commonly admin.yourcompany.com, but it is whatever you enter in the platform.
Your Borrower Application Domain
Where your clients submit applications. Commonly app.yourcompany.com or apply.yourcompany.com.
Who you bought the domain from
The registrar. This is often NOT the company that controls your DNS.
Your current nameservers
Nameservers determine which provider is authoritative for your domain, and that is where DNS records must be created. Step 2 shows you how to find them.
Your business email provider
Google Workspace, Microsoft 365, a free consumer account, or email included with your web host. Each behaves differently.
Whether you have an existing website on this domain
So nothing you already run gets taken offline by a DNS change.
Account access and permissions for all of the above
Someone who can sign in and make changes without waiting on account access or permissions from a third party.
A note on who controls your DNS
- The company that sold you your domain is often not the company that controls its DNS records. This trips up more setups than any other single thing.
- What decides it is your nameservers. Whichever provider your domain's nameservers point to is the authoritative DNS for that domain, and that is the only place a record change takes effect.
- Moving a website to a site builder, or putting a domain behind a CDN, sometimes moves nameservers and sometimes does not. Do not assume either way — check the nameservers.
- Step two shows you how to find out for certain in under a minute.
Step two
Point your domains at the platform
Two DNS records. That is the whole job. The difficulty is not the records — it is making them in the right place, with the right host value, without breaking the website or email you already run.
First: find who actually controls your DNS
- Go to lookup.icann.org and enter your domain.
- Read the Registrar Information section — that is who sold you the domain.
- Read the Nameservers under Domain Information — those decide which provider is authoritative for your domain.
- Sign in to that provider's DNS editor. If you are not certain which account the nameservers belong to, send us the nameserver values before you change anything.
The name inside a nameserver address is a strong hint, but it is not proof. Hosts, agencies, and resellers often run branded or white-label nameservers under their own domain, and a domain’s DNS can be delegated to a provider whose name appears nowhere in your records. If the nameservers do not match an account you can sign in to, ask whoever set the domain up, or send us the values and we will identify the provider.
The two records you are creating
Both are type A. Both point to the same address. Only the host differs.
Where to find your exact values
Sign in to your portal and open Settings → Custom Domain. The “How to Setup DNS Configuration” panel shows both records with the exact Name/Host and the address to point them at. Copy the value from that screen — it is the authoritative source, and it stays correct even if the platform destination changes.
Partner Portal
- Type
- A
- Name / Host
- The subdomain label of your Partner Portal Domain
- Points to
- The address shown on your Custom Domain screen
Borrower Application Portal
- Type
- A
- Name / Host
- The subdomain label of your Borrower Application Domain
- Points to
- The address shown on your Custom Domain screen
The single most common mistake
- DNS editors differ. Some expect a relative label — admin, app, apply — and append your domain automatically. Others expect the fully qualified hostname, admin.yourcompany.com, sometimes with a trailing dot. A few accept either.
- Typing admin.yourcompany.com into a field that appends automatically produces admin.yourcompany.com.yourcompany.com, which resolves to nothing and usually gives no error at all.
- Work out which kind you are in before you save. If the provider shows your domain greyed out beside the input, or its own help text uses a bare label in its example, enter the label only.
- cPanel-style Zone Editors commonly append the domain and display full hostnames in the record list, but behaviour varies by host and version. Save one record, then read it back in the list to confirm the hostname came out the way you intended before you create the second.
Do not delete records you do not recognise
- Your existing MX records carry your business email. Removing them stops mail immediately, and the sender gets no bounce for hours.
- TXT records that look like random strings are usually domain verification for services you still use — email, analytics, advertising, e-signature.
- Never delete a record you do not recognise. Nothing in this setup requires removing a record that is not at the exact hostname you are configuring.
- A conflict is normally an existing A, AAAA, or CNAME at that exact hostname, but other record types and provider-specific entries can also stand in the way, and a CNAME at a name blocks every other record at that same name.
- If a record is in the way and you do not know what it does, send us a screenshot before deleting it.
Instructions for your provider
Open the one that matches where your DNS actually lives — not necessarily where you bought the domain.
How long this takes to work
- A brand-new hostname often resolves within minutes. It is usually quicker than changing an existing record, though not always — if anything already queried that hostname and got no answer, resolvers may cache that negative answer for a period set by the zone's SOA record.
- Changing an existing record takes longer, because the previous value stays in resolver caches until its TTL expires. Lowering the TTL before a planned change shortens that window; lowering it afterwards does not.
- The 24 to 48 hour figure is a conservative worst case. Delays come from a mix of TTLs, intermediate resolver behaviour, and caching at the operating system and browser level, so it is not attributable to any single cause.
- If it has been more than 48 hours, something usually needs correcting rather than more waiting — most often the record itself, but sometimes the nameservers, a conflicting record, or an unfinished verification step. Go to the troubleshooting table, and send us a screenshot if it is not obvious.
Step three
Connect your outgoing email
This is how your platform sends notifications, receipts, and system alerts to your clients. It is the step partners most often rush, and the one that most often causes problems weeks later.
Choose the right option, not the fastest one
- Your business mailbox and your platform's sending account do not have to be the same thing, and usually should not be.
- A free consumer account is not a business email account. They differ in the ways that matter here — sender identity, authentication, sending limits, and administrative control.
- If you expect meaningful notification volume, a service built for application-generated mail is worth considering. It separates platform notifications from the mailbox your team reads, and it does not share that mailbox's limits.
- Whatever you choose, the credential goes into Settings, Email Configuration in your own portal. It is never sent to us.
Credentials
- Never send a password, app password, secret key, or API key to anyone — by email, by text, or in a support conversation. That includes us. We will never ask.
- Enter every credential directly into Settings, Email Configuration in your own portal.
- If you have already sent a credential to someone, revoke it and generate a new one rather than hoping.
Step four
Prove the mail is really from you
SPF, DKIM, and DMARC are DNS records that let a receiving mail server confirm your notifications really come from you. Without them, or with them configured incorrectly, mail is much more likely to be filtered or rejected — and receivers differ in how they treat it, so the symptoms are inconsistent and hard to diagnose.
If you remember one thing from this step
- Your sending domain may publish exactly ONE SPF record. Adding a second does not add a sender — it breaks SPF for the whole domain, which is worse than having none.
- Check what is already published before you touch anything. If a record exists, read what it authorises, merge the new mechanism into it, and validate the result.
- Take DKIM selectors from your provider's console. Never invent one, and never reuse one from another domain.
Step five
Make it yours
Settings, Branding. This is what your clients see, and it is the part of a white-label platform that either reads as your business or reads as somebody else's software with your name on it.
Fields and specifications
Where it lives
Settings, then Branding
The screen is headed Brand Settings. What you set here applies to the partner portal, the borrower portal, your emails, and your invoices.
Preview
Updates as you edit
The screen previews the portal, a phone view, an email, and an invoice. Use it — it shows the combinations most likely to go wrong before you save anything.
Site name
Required
Under Identity. Your name as it appears in the portals, your emails, and your documents.
Slogan
Optional
Under Identity. A short line shown alongside your name. Leave it blank rather than filling it with something you will regret.
Logo uploads
As specified on the screen
Each upload slot states the file type and the dimensions it expects. Take those values from your own Branding screen rather than from this page, and prepare the file to match before you upload it.
Favicon
As specified on the screen
The small square icon that appears in the browser tab. The screen states the accepted format and size.
Theme colours
Hex values
Your dominant colour and your accent colour. Check how each one reads against the preview before saving.
Getting it right
- Upload the correct logo variant to each slot. The most common branding mistake is putting a dark-text logo into the slot used on the dark navigation bar, where it renders as an invisible smudge.
- Use transparent backgrounds. A white rectangle behind your logo is obvious against a coloured header and looks unfinished to your clients.
- Match the dimensions the screen asks for, and keep your original aspect ratio within them. A square logo stretched into a wide slot looks distorted on every screen your borrowers see.
- Check contrast before you commit. A pale accent colour makes button text unreadable, and it is usually the button your borrower needs to press.
- Check the dark and light cases separately. A logo that reads well on the dark navigation bar can disappear on a white email background, and the reverse is just as common.
- Use the on-screen preview as you go, then save, then reload the portal in a private browser window to confirm what a new client actually sees.
Step six
Connect how you get paid
Settings, Payment Integration. Six methods are available. Four are connected processors that use credentials — Stripe, Ecrypt, Square, and Authorize.Net. Two are manual methods that do not — Cash Payment and Bank Transfer. Each carries its own Active Status, and each connected processor has its own sandbox and production environment, so review all six before launch rather than discovering later that one was live all along.
Worth knowing
- Settings, Payment Integration lists six payment methods: Stripe, Ecrypt, Square, Authorize.Net, Cash Payment, and Bank Transfer. Each row shows its active status, and a connected processor also shows which environment it is operating in.
- Stripe, Ecrypt, Square, and Authorize.Net are connected methods configured with processor credentials. Cash Payment and Bank Transfer are manual methods and take no processor credentials.
- The short description beside each method on that screen is the platform's own description of what that integration handles. Open the method itself to see the fields it actually asks you for.
- Each method carries its own Active Status, and each connected processor carries its own Operating Environment. Review all six before launch, rather than assuming a method you never opened is switched off.
- Confirm the Operating Environment before entering any credential, and confirm the credential was issued for that same environment.
- Test each connected processor in Sandbox before taking real payments through it.
- Activate only the methods your business actually intends to offer.
- Never send API keys, client secrets, access tokens, transaction keys, or banking details to anyone by email, text, or chat — including to us.
Step seven
Publish your business loan application
Embedded Form. This is how you take applications from people who are not signed in to your portal — a direct link you can send, or an iframe you place on your own website. Both carry your brand, and both land in your tenant.
How it fits together
- The embedded form is how you accept applications outside the authenticated portal — a direct link you can send, or an iframe on your own website.
- The direct link is the flexible one. It is what you put behind an Apply Now button, send in an email or an SMS, encode in a QR code on printed material, or include in outreach.
- The iframe keeps the application inside a page of your own site. The embed snippet is generated in your portal and can be pasted into WordPress, Webflow, Shopify, or any custom website.
- Form Status must be Active before either the link or the iframe will accept a submission.
- Allowed Domains is optional and applies to embedding. The direct link works without it.
- Test with a complete submission, including a document upload, from both desktop and a phone before launch.
- Treat Regenerate Public Key as a last resort. It breaks links and embeds that are already published.
Before you regenerate your key
Regenerate Public Key is a revocation action, not a refresh. It can stop every link you have already sent and every website embed you have already published from working. Use it when you intend to revoke access, and only when you are ready to replace the link and the embed code everywhere you have put them.
Step eight
Company details, users, and permissions
Where each setting actually lives in your portal, and the decisions about who inside your business can reach what. If a setting you expect is not listed, ask us where it is rather than hunting — menus also vary with the permissions of the account you sign in as.
Your name, slogan, logos and colours
Settings, then Branding
Set once, under Identity and the sections below it, and used across the partner portal, the borrower portal, your emails and your invoices. Covered in step five — it is listed here so you know this is the one place it is set.
Your portal addresses
Settings, then Custom Domain
Your Partner Portal Domain and your Borrower Application Domain, and the DNS values that make them resolve. Covered in step two.
The address your platform mail is sent from
Settings, then Email Configuration
The sending configuration and the From address your clients see. Use an address your business actually monitors, and confirm a reply to it lands somewhere a person reads. Covered in step three.
Sending a test message
Settings, then Test Mail
Sends a message using your saved configuration. Use it after every change to the email settings, not only the first time.
Your client agreements
Settings, then Agreement Builder
Where your client-facing agreement content is maintained. These are your agreements with your clients, so they are yours to draft and yours to have reviewed.
How you get paid
Settings, then Payment Integration
The six payment methods, their active status, and their credentials. Covered in step six.
Your application form
Embedded Form, then Configuration
The public application, its title, its status, allowed domains for embedding, and the link and embed snippet you publish. Covered in step seven.
Your staff records
Employees
Your employee records. Keep this current as people join and leave — it is the list you will check against when you audit access.
Who can sign in
Users
The accounts that can actually reach your portal, and the role each one holds. This is the list that matters for access, and it is the one to review when someone leaves.
What each role can do
Roles & Permissions
Roles are listed as cards showing the permissions each one carries and how many users hold it. Add Role creates a new one, Edit Role changes an existing one, and View Users shows who holds it. Read a role's permissions before you assign anyone to it.
Access control
- Review Roles & Permissions before you add your team, not after. It is far easier to grant an additional permission than to work out who has been able to see what.
- Grant the least access each person needs to do their job, and no more. Decide by the permissions a role carries rather than by how senior someone is, and review the roles again whenever someone's responsibilities change.
- Keep the number of people who can change platform settings to the minimum your business can operate with, and know who they are at any given moment. Settings changes affect what live clients see.
- Some screens hold applicant personal information and uploaded documents. Treat access to those as a separate decision from access to settings, and give it to fewer people than you first think.
- When someone leaves, remove their access the same day. Platform access outlives an email account.
Your legal documents are yours
Your client agreements, your privacy policy, and your terms must be your own documents, reviewed by your own counsel, covering your own business. Do not point them at ours and do not adapt ours. Your clients are contracting with you, not with us.
Step nine
Verify before you launch
Configuration is not completion. Work through every applicable item with your own eyes before a single real client touches the platform. Anything that genuinely does not apply to your setup can be marked N/A — it drops out of the count rather than sitting there unfinished.
Launch readiness
0 / 36verified
Mark anything that does not apply to your setup as N/A — it stops counting. Saved in this browser only. It is a working aid, not a record of completion.
Domains and security
0/5Access
0/3Embedded form and borrower intake
0/12Notifications
0/5Brand and presentation
0/5Payments
0/6When it does not work
Troubleshooting
Find the symptom. Almost every setup problem is one of these, and almost none of them are propagation.
Symptom
The portal address does not load at all
Usually means
The A record was created at a provider that is not authoritative for your domain, or the host field contains the full hostname where only the label was expected.
What to do
Check your nameservers at lookup.icann.org to confirm who actually controls DNS, then confirm the record exists there with the label-only host value.
Symptom
It works sometimes and fails other times
Usually means
More than one A record exists for the hostname and they point to different places, so traffic alternates between the old destination and the platform. Multiple A records at one hostname are legitimate when they are deliberate load balancing — here they usually are not.
What to do
List every A record at that exact hostname. Keep the one pointing at the platform destination, and edit or remove the others once you have confirmed what they were serving.
Symptom
It works for some people but not others, on the same network
Usually means
An AAAA (IPv6) record exists for the hostname and points somewhere other than the platform. Devices with working IPv6 prefer it and never reach the platform; devices without it work normally.
What to do
Check whether the platform publishes an IPv6 destination for your hostname. If it does, correct the AAAA record to match. If it does not, remove the AAAA record for that hostname only, and leave AAAA records on every other hostname alone. AAAA records are not a problem in themselves — one pointing at the wrong place is.
Symptom
The DNS provider refuses to save the A record
Usually means
A CNAME record already exists at that name. A CNAME cannot coexist with any other record at the same name.
What to do
Find out what the CNAME points to and what it is currently serving. Confirm you are intentionally replacing that service, then remove the CNAME and add the A record.
Symptom
The browser shows a certificate or security warning
Usually means
Several things produce this. The certificate has not finished issuing yet. On Cloudflare, the record is Proxied, so validation reaches Cloudflare rather than the platform. The hostname you are visiting is not the exact hostname configured in FCH — including a www variant that was never configured. A DNS record points somewhere other than the platform. Or the certificate issued but is for a different hostname.
What to do
Confirm the hostname in the address bar matches exactly what is configured under Settings, Custom Domain. Confirm the DNS records resolve to the platform destination, and on Cloudflare that they are DNS Only. Then allow the stated time for issuance before concluding it failed. If the warning names a hostname or an issuer, send us a screenshot of the full warning — that detail usually identifies the cause immediately.
Symptom
The domain has been pending or unverified for more than 48 hours
Usually means
At this point it is usually a configuration problem rather than a delay, though not always — a very long TTL on a previous record, or an incomplete verification step, can also account for it.
What to do
Verify the record type, the exact hostname, the destination value, and that the records exist at the authoritative nameservers. Check for a conflicting record at the same hostname. If all of that is correct, send us a screenshot of your DNS screen rather than waiting longer.
Symptom
Test mail fails to send
Usually means
Almost always the credential or the authentication method rather than the host and port. Microsoft 365: a normal sign-in password was entered instead of an App Password, the App Password was revoked, SMTP AUTH is disabled for the mailbox or at the tenant level, or tenant security policy is blocking the connection. Google: the account password was used instead of a Google App Password, or 2-Step Verification is off so no App Password exists. Amazon SES: IAM access keys were pasted in place of SES SMTP credentials, or the credentials belong to a different region.
What to do
Microsoft 365 — check the App Password first. Generate a fresh one and enter that, never the mailbox sign-in password, then confirm SMTP AUTH is enabled for the mailbox and at the tenant level, and that the host is smtp.office365.com on port 587 with STARTTLS. Google — confirm 2-Step Verification is on and that the password field holds a Google App Password for that mailbox. Amazon SES — confirm the values came from SMTP settings, Create SMTP Credentials rather than from IAM, and that they match the region you verified the domain in. If a security configuration is blocking the connection, do not weaken it to get around the block.
Symptom
Mail sends but never arrives
Usually means
The platform reports success because the sending server accepted the message — what happened afterwards is a separate question. Common causes: Amazon SES is still in the sandbox, so delivery is restricted to verified recipients. A sending limit has been reached. The recipient's provider is silently discarding unauthenticated mail. A DMARC policy is quarantining or rejecting it. The recipient has a rule filing it somewhere. The From address is wrong. Or the recipient address itself is wrong and the bounce went to an unmonitored mailbox.
What to do
Send to two addresses on different providers and see whether both fail. Confirm SES production access if you are on SES. Check the sending account's own sent and bounce records. Then confirm SPF, DKIM, and DMARC all pass on a message you actually receive, and check your DMARC policy is not acting on a failure you have not noticed.
Symptom
Notifications land in spam
Usually means
Usually authentication: SPF failing, DKIM not signing or signing with a selector that is not published, DMARC not aligning, or the From address not matching the authenticated domain. It can also be reputation rather than authentication — a shared sending IP, a brand-new sending domain with no history, a mismatch between the sender name and the domain, or content and link patterns the receiver distrusts. Receivers differ, so it can fail at one provider and pass at another.
What to do
Check all three on a message you actually received, reading the headers rather than guessing. A second SPF record on the domain is a common cause and invalidates SPF entirely. Confirm the DKIM selector in the signature is one your provider issued and you published. If authentication is passing everywhere and mail is still filtered, the issue is reputation — send us an example and we will look at it with you.
Symptom
Email stopped working weeks after it was set up correctly
Usually means
An App Password or other credential was revoked, SMTP AUTH was disabled for the mailbox or tenant, a security or Conditional Access policy changed, a mailbox or account setting changed, or the provider changed what it requires.
What to do
Generate a new App Password and update it in Settings, Email Configuration, then confirm SMTP AUTH is still enabled and that no security policy now blocks it. If the failure is caused by legacy-authentication restrictions, move to a supported modern-authentication configuration when one is available rather than weakening account security to restore it.
Symptom
The logo is invisible or looks like a dark smudge
Usually means
A dark-text logo was uploaded to the slot used on the dark navigation bar, or a logo with a white rectangle behind it was uploaded instead of a transparent one.
What to do
Go to Settings, Branding and swap the logo variants so the light version sits in the slot used on dark backgrounds and the dark version in the slot used on light ones. Use the on-screen preview to confirm both before saving.
Symptom
A payment fails immediately in testing
Usually means
The saved credentials were issued for a different environment than the one selected in FCH, only part of a credential pair was replaced, the integration's Active Status is off, or the credentials have been rotated or revoked at the processor.
What to do
Confirm that the credentials were issued for the same Sandbox or Production environment selected in FCH. Replace both halves of a credential pair together, confirm Active Status is on, and if the values were rotated at the processor, issue a fresh set and save them again.
Still stuck
Send a screenshot, not a description.
Nine times out of ten we can see the problem immediately in a picture of your DNS screen or your settings page — and nine times out of ten a written description leaves out the one field that matters.
Send enough of the settings screen to show the field names, safe configuration values and exact error. Before sending, redact all sensitive information.
Book time with your implementation specialist.
Redact before you send
We never need any of the following in order to help you, and we will never ask for them. Cover them, crop them out, or black them over before the screenshot leaves your machine.
- Passwords and App Passwords
- API keys, secret keys, Client Secrets, Access Tokens, and Transaction Keys
- Bank account numbers, routing numbers, and SWIFT or IBAN values
- Card numbers, expiry dates, and security codes
- Social Security numbers and other taxpayer identification numbers
- Driver's licence and state ID images or numbers
- Borrower and applicant personal information, including names, addresses, email addresses and phone numbers
- Bank statements and any financial document uploaded by a client
- EIN documents and business formation documents
- Authentication codes, recovery codes, and backup codes
If you have already sent a credential to anyone, revoke it and issue a new one rather than hoping it was not seen.