Cevrynt × SHOPLINE
A documented development and referral partnership around e-commerce merchant-underwriting workflows.
How a referral moves
A route a merchant can choose, not a pipe they are already in.
Four parties, and between each pair a gate that only opens when a named party says yes. Above the track, the shortcuts people assume a platform partnership creates — each one struck through.
- 04
- Parties on the path
- 03
- Points that need a yes
- 00
- Steps that happen by themselves
- 04
- Shortcuts it does not take
Shortcuts a reader might assume · none of them exist
- The merchantRuns their business on SHOPLINE, and decides whether to look for financing at all.Gate 01The merchant chooses to be referred.
Coordinates a qualified referral under the documented partnership.Gate 02The merchant authorises what may be shared, for this workflow only.
Structures the underwriting file for a lender, with the evidence attached.Gate 03The lender's own eligibility criteria and policy apply.- The lenderApplies its own policy and makes every credit decision.Decides · including no
- Commerce data shared automaticallyNot part of it
- A credit decision made by CevryntNot part of it
- Eligibility set by the platformNot part of it
- Funding guaranteed by being on the platformNot part of it
Nothing on this path moves by itself
Choose a gate to read what has to be true before anything moves past it, and who decides. Above the track are the shortcuts people tend to assume a platform partnership creates; each one is struck because none of them exists.
Why a path of decisions and not a flow of data
The easiest way to draw a platform partnership is as a pipe: merchant data in one end, underwriting out the other. That drawing would describe a live integration and automatic data sharing, and this partnership is neither — so the figure draws the people who have to say yes instead.
Two of the three gates belong to the merchant and one to the lender. None belongs to SHOPLINE or to Cevrynt, which is the point: the partnership coordinates development and qualified referrals, and every decision that matters to a merchant or a lender stays with them.
Who holds each decision
- Whether to be referredThe merchant
- What may be sharedThe merchant
- Eligibility and pricingThe lender
- The credit decisionThe lender
The partnership coordinates development and qualified referrals. It does not move a merchant's data, set eligibility or fund anything, and lenders remain independent in every decision they make.
Three gates, three yeses, and not one of them given by the partnership itself. That is what a documented development and referral partnership looks like when it is drawn honestly: a route a merchant can choose, not a pipe they are already in.
What it covers
The partnership surrounds the work. The decision sits at the centre, out of its reach.
Three rings of scope — the lender’s decision, Cevrynt’s review, and the documented partnership — with the seven things it is not set out beside them at the same weight.
- 03
- Rings of scope
- 07
- Things the partnership is not
- 00
- Decisions the partnership takes
Outside every ring
- A generally available live integration
- An investment
- Exclusivity
- An endorsement
- Automatic data sharing
- Universal merchant eligibility
- Guaranteed funding
The decision is in the middleChoose a ring to read what sits inside it. The partnership is the outer ring: it surrounds the work, and reaches neither the review nor the decision.
Why the outside is listed at the same weight
A reader who only saw what a partnership includes would fill in the rest for themselves, and the usual assumptions about a platform partnership — an integration, an investment, an endorsement, some kind of eligibility — are exactly the ones that are not true here.
So the seven things this partnership is not sit beside the three rings it is, in the same type and at the same size. The shape does the rest: the decision is at the centre, and the partnership is the ring furthest from it.
What the partnership documents
- Workflow developmentDocumented
- Qualified referralsCoordinated
- Lender eligibilityIndependent
- Credit decisionsIndependent
Cevrynt is not a lender. It issues no approval, decline or price, and lenders retain final authority over every file — including every file that arrived through a referral.
Three rings, and the partnership is the outermost. It surrounds the work of building better e-commerce merchant underwriting; it does not reach the review, and it never reaches the decision.
What is being developed
Five questions the partnership is working through, and not one feature.
Each question is marked against where an answer could come from: the bank statements already in any file, commerce context only where a merchant has authorised it, or the lender’s own policy.
- 05
- Questions being worked through
- 04
- That need commerce context, only if authorised
- 01
- Only a lender can answer
- 00
- That are live features
Available in any fileOnly where the merchant has authorised itWritten by the lender
Questions, not featuresChoose a question to read what it is actually asking. Every row carries the same status on purpose: these are questions the partnership is working through, and none of them describes something that is available today.
Why the page lists questions instead of capabilities
A development partnership is easy to overstate. Put a question in a product-page layout and it reads like a feature, and the gap between the two is precisely what a lender or merchant is entitled to know about. So everything here is phrased as a question and marked with the one status that is true of all of them.
The marks are the other half of the honesty. Four of these questions need commerce context, and commerce context is conditional in a way bank statements are not — which is why those marks are drawn open, inside a dashed ring, and why the next section is about what has to be true before any of it is used.
What a question here is not
- A shipped capabilityNo
- A commitment to a dateNo
- Data already being usedNo
- A change to lender policyNo
These are the e-commerce merchant-underwriting questions the partnership exists to develop. Where commerce context would help answer one, it depends on the conditions set out in the next section — and the lender decides whether it has any place in the review at all.
Five questions, one status. Four would need commerce context a merchant has authorised, one can only be answered by a lender, and none is a feature — which is the most useful thing a development partnership page can say plainly.
Before any commerce context is used
Four conditions, joined by “and”. Miss one and the file is worked from documents.
The implementation, the merchant’s authorisation, permitted access and the lender’s use case — each a switch wired into one gate that only opens when all four hold.
- 04
- Conditions that must all hold
- 01
- Missing is enough to fall back
- 00
- Met by the partnership on its own
Switch conditions on to see what changes · they start off because nothing is assumed
There is no general-purpose connection to switch on. Anything beyond submitted documents depends on an implementation agreed for the specific use case.
Given by the merchant, for this workflow. Being on the platform is not authorisation, and without it nothing is used.
Only what the permitted access covers, and only for the purpose it was permitted for — not everything a platform happens to hold.
The lender decides whether commerce context has any place in its review. A lender that does not use it is not missing anything the partnership requires.
Not all four hold
Submitted documents only
The file is worked exactly like any other. Nothing is assumed, nothing is filled in, and what is missing is named:
- A specific implementation, agreed for the use case
- The merchant's authorisation
- Permitted data access
- A lender use case that calls for it
Why a gate, and not a list
Every page on this site that mentions SHOPLINE says the same thing: any production data flow depends on the specific implementation, merchant authorisation, permitted data access and the lender's use case. Written as a sentence, that reads like four considerations. It is four conditions joined by "and".
So the figure computes it. Turn one off and the output falls back to submitted documents and names what is missing. The switches start off because that is the honest default, and none of the four can be met by the partnership on its own — two belong to the merchant and the lender outright.
When a condition is missing
- Commerce context used anywayNever
- Gaps filled by inferenceNever
- The file still workedFrom documents
- What is missingNamed
The partnership does not imply a generally available live integration or automatic data sharing. Where the conditions are not all in place, a merchant's file is reviewed from the documents submitted, and the lender's authority over the decision is unchanged either way.
Four conditions, one gate, and the gate opens only when all four are true. That is the whole of what "it depends on the implementation, the merchant's authorisation, permitted access and the lender's use case" means — drawn so it cannot be read as anything looser.
For lenders
Two doors, one file. A referral changes how a merchant arrives, not how the file is read.
A referred file and a directly submitted one merge before the first stage and run as one line through all eight. Only two stages show the route at all, and neither lowers the bar.
- 08
- Stages every file passes
- 06
- Identical whichever way it arrived
- 02
- Where the route shows at all
- 00
- Stages eased for a referral
Two doors, one line
Choose a stage to set the referred file beside the direct one. Six stages are identical. Intake notes the route, and Financials is the one place commerce context could be added — only where all four conditions hold.
Why a referral gets no lane of its own
A referral that bought a softer review would be worth less to a lender, not more: every file from that route would need a second look. The value of a referral is that it reaches the same review, under the same policy, as everything else.
So the two doors merge before the first stage. The only mark the route leaves is a note at intake for the audit trail, and the only possible addition is commerce context — which is context for the underwriter, never a substitute for the documents and never a decision.
What a referral changes
- The documents requiredNothing
- The checks that runNothing
- The lender's policyNothing
- Who decidesNothing
A referred merchant is reviewed like any other applicant to that lender. The lender may still decline, and a referral is never an indication that it will not.
Two doors, one file. A referral changes how a merchant arrives, not how the file is read — and the lender's decision at the end of the line is the same decision either way.
Where to go from here
Three readers, three routes, and none of them is an application.
A merchant, a lender and a platform read this page for different reasons. Each gets what the partnership means for them, what it does not, and where to go next.
- 03
- Readers this page is for
- 05
- Places to go next
- 00
- Funding applications taken here
01A merchant selling on SHOPLINE
- What it means for you
- Cevrynt is software that lenders use to review a financing file. It is not a lender: it does not offer funding, take funding applications, or decide whether a business qualifies.
- What it does not mean
- Selling on SHOPLINE does not make a business eligible, pre-approved or referred, and no store data is shared because this partnership exists.
02A lender funding e-commerce merchants
- What it means for you
- A route by which qualified e-commerce referrals may be coordinated, and a review that treats each one exactly like any other file under your own policy.
- What it does not mean
- No obligation to fund a referral, no eligibility criteria set for you, and no commerce context unless all four conditions hold for your use case.
03A commerce or embedded-finance platform
- What it means for you
- An example of how a development and referral partnership can be structured: workflow development and coordinated referrals, with every credit decision left with lenders.
- What it does not mean
- Not a programme to join or an integration to switch on. Any conversation starts from your own merchants, your permissions and the lenders involved.
Why the merchant's route ends at information
A page about a platform partnership is easy for a merchant to read as an invitation to apply. It is not one, and the kindest thing the page can do is say so before anybody fills in a form expecting funding.
Lenders and platforms get a conversation, because a walkthrough or a founder call is genuinely where their questions get answered. A merchant gets the FAQ and the explanation of how e-commerce files are reviewed — because the decision about their financing belongs to a lender, not to Cevrynt or SHOPLINE.
Who to contact, for what
- WalkthroughsCalendly
- Partnership questionsarin@cevrynt.com
- Sales enquiriessales@cevrynt.com
- Funding applicationsNot taken
Cevrynt does not lend, broker or arrange funding. Questions about financing a specific business belong with a lender, and every decision about it stays with that lender.
Three readers, three routes, and not one of them ends in an application — because the only party that can say yes to funding is a lender, and this page should never suggest otherwise.
Founder-led
Ask what the partnership covers — and what it does not.
If you lend to e-commerce merchants and want to understand where this work is heading, we will walk you through what the partnership documents, what is still being developed, and where your own policy stays in charge of every decision.