Build guide

Merchant Cash Advance Page

Create a conversion-focused merchant cash advance product page on the client’s existing site. Use the supplied written page as the sole source for headings, body copy, figures, disclosures and CTA language.

Part 1Build objective

The finished page must:

  • Present the merchant cash advance as the client’s own funding product.
  • Put the application and core terms within the first screen.
  • Explain mechanics, costs, qualification and risks openly.
  • Keep every substantive answer visible without requiring expansion.
  • Lead readers back to one short application form or the published phone number.
  • Reuse the site’s existing theme, navigation, footer, form infrastructure, design tokens and legal components.

Do not rewrite, abbreviate or reorder the supplied sections unless needed to correct heading hierarchy.

Part 2Route and page shell

Use the clean canonical route:

/merchant-cash-advance/

Place the page inside the site’s normal global shell:

  1. Existing header and navigation
  2. Optional existing breadcrumb component
  3. Main page content
  4. Existing footer and legal links

If the site uses breadcrumbs, use the real site hierarchy. Do not invent a parent page that does not exist.

Use one <main> landmark and exactly one <h1>.

Suggested section IDs

Assign stable IDs so buttons and deep links work:

#mca-application
#mca-terms
#how-it-works
#mca-cost
#mca-requirements
#mca-uses
#how-to-apply
#mca-comparison
#straight-answers
#mca-reviews
#get-an-offer

Apply scroll-margin-top to anchored sections to account for a sticky site header.

Part 3Content and factual-data rules

  • Preserve the writer’s headings and wording.
  • Use the supplied figures for amount ranges, factor rates, minimum revenue, credit thresholds, time in business, approval speed, funding speed and term ranges.
  • Do not invent a term, fee, discount, guarantee, approval rate, review, rating or funding statistic.
  • Resolve any data tokens from the site’s existing approved product configuration or live application data. If no approved value exists, omit the unsupported claim or row rather than publishing a placeholder.
  • Ensure the initial application really uses a soft credit inquiry before displaying that claim. Do not route this form into a hard-pull workflow.
  • Do not describe the MCA as a loan in interface labels or structured data.
  • Use the client’s approved legal language for consent, personal guarantees, UCC filings, reconciliation, credit pulls and state disclosures.
  • Keep state disclosure information in an editable CMS field so legal staff can update it without rebuilding the page.

Part 4Page structure

A. Hero and application

Build a two-column hero inside the site’s standard wide container.

Desktop

  • Left column: approximately 55–60%
  • Right column: approximately 40–45%
  • Vertically align the form card with the start of the hero copy.

Left column

Render, in order:

  1. H1
  2. Two-line introductory copy
  3. Speed or funding-stat line
  4. Primary CTA only if the site convention requires one in addition to the visible form; it should link to #mca-application

Keep the introduction readable and left-aligned. Do not add a logo strip, awards row or generic “why choose us” block.

Right column: application card

Use the existing lead form component and connect it to the client’s real lead/application system. Give the form wrapper:

id="mca-application"

Include the supplied form heading, review-rating line, all required fields, submit button, soft-pull statement and consent text.

Expected fields:

  • Name
  • Email
  • Phone
  • Business name
  • Time in business
  • Average monthly deposits or revenue
  • Confirmation that revenue is deposited into a business bank account
  • Required consent control where applicable

Use the current backend taxonomy for dropdown values. If the backend stores first and last names separately, a single visible name field may be mapped internally.

Form requirements:

  • Persistent <label> elements; do not rely on placeholders as labels.
  • Appropriate autocomplete, inputmode and field types.
  • Inline validation and a clear error summary.
  • Preserve values after a failed submission.
  • Server-side validation and spam protection.
  • Do not transmit field values to analytics.
  • Retain UTM and approved attribution parameters in hidden fields.
  • Include hidden product/source values identifying the lead as an MCA-page application.
  • On success, use the site’s real confirmation or next-step flow.
  • On failure, show an actionable error and preserve the form.
  • The initial submission must not initiate a hard credit pull.

Place the real aggregate rating and review count beside or directly under the form heading. Link it to #mca-reviews or the verified review platform. Do not use a static rating that can drift from the source.

Mobile

Stack in this order:

  1. H1 and opening copy
  2. Speed/stat line
  3. Application card
  4. Terms table

Do not hide or defer the form behind a modal.

B. MCA terms at a glance

Place this immediately below the hero, in the same visual opening section. Use the writer’s subheading followed by a two-column semantic table.

Include every supplied key fact, such as:

  • Funding amount
  • Expected collection or term range
  • Starting factor rate
  • Remittance frequency
  • Approval time
  • Funding time
  • Minimum time in business
  • Minimum monthly revenue or deposits
  • Credit floor
  • Collateral
  • Permitted use of funds

Use:

<table>
  <caption>...</caption>
  <tbody>
    <tr>
      <th scope="row">...</th>
      <td>...</td>
    </tr>
  </tbody>
</table>

The visible heading may serve as the caption if connected accessibly. Do not represent these facts as a row of vague icon cards.

C. What an MCA is and how it works

Use a standard content section with the writer’s H2.

Render:

  1. Definition paragraphs
  2. The “sale of receivables, not a loan” explanation
  3. Four-step ordered list
  4. Remittance-method introduction
  5. Two side-by-side text cards:
    • Percentage-of-sales/holdback structure
    • Fixed daily or weekly ACH structure

The cards should have text headings and full visible explanations. Do not use icons in place of labels.

On mobile, stack the cards. Keep the reconciliation explanation inside the fixed-remittance card rather than as a tooltip or footnote.

D. Cost section

Use the writer’s cost heading as an H2. Keep this section visually prominent but not promotional.

Render the supplied factor-rate explanation first, followed by the worked example as a real table.

The example table must show both sales scenarios and all supplied values, including:

  • Advance
  • Factor rate
  • Total amount collected
  • Cost in dollars
  • Daily or weekly remittance
  • Expected collection period
  • Monthly-sales scenario

Use a caption or short text immediately below the table explaining that the total owed remains fixed while remittance and duration may change with sales.

After the table, render the supplied passages on:

  • APR and annualized comparisons
  • Fees outside the factor rate
  • Early payoff and any available discount

Keep all three visible. Do not replace the worked example with a calculator.

If the site already has a live, relevant MCA estimator, link the supplied calculator phrase to it. Do not create an empty or nonfunctional calculator link.

E. Qualification and documents

Build a two-column section.

Primary column

Render:

  • Requirements heading
  • Minimum-requirements checklist
  • Credit-check explanation
  • Bad-credit explanation
  • Startup eligibility
  • Collateral, guarantee and UCC explanation
  • Approval-improvement tips
  • Documents list

Use real list markup for checklists. Avoid green checkmarks for items that are merely requirements rather than benefits.

Secondary column

Use an approved image of a relevant small-business owner from the client’s existing asset library. Give the image explicit dimensions and responsive sources.

  • If the image adds information, write an accurate alt description.
  • If it is decorative, use alt="".
  • Do not create fake customer imagery or associate a stock person with a testimonial.
  • If no approved image exists, use a wider text layout rather than inserting an unapproved placeholder.

On mobile, place the image after the minimum-requirements checklist so it does not delay the answer.

F. Uses and fit test

Create a two-column block:

  • Left: allowable uses checklist
  • Right: business types that commonly fit the product

Below both columns, place the four-point fit test as a numbered or bulleted list, followed by the writer’s conclusion about when another product may fit better.

Do not add industry or location landing-page links to every business type. Link only where the supplied copy calls for a relevant existing resource.

G. Application process

Render the supplied four-step process as a vertical timeline or numbered step list. Each step must include its timing and required action.

Use semantic ordered-list markup underneath the visual treatment:

<ol class="application-steps">
  <li>...</li>
</ol>

Include the CTA after the final step. It should scroll to #mca-application, not open a duplicate form.

Place the direct-funder statement immediately below the CTA. Do not imply that the client funds directly if the supplied copy says partners are involved.

On desktop, the timeline may use a vertical rule. On mobile, retain visible step numbers and remove decorative elements that crowd the content.

H. Comparison with the client’s other products

Render the supplied introductory comparison paragraph, followed by one side-by-side comparison table.

Columns should contain only products the client actually offers, typically:

  • Merchant cash advance
  • Working capital or business loan
  • Business line of credit

Rows should include the supplied attributes:

  • Best for
  • Repayment rhythm
  • How cost is expressed
  • Approval speed
  • Funding speed
  • Amount range
  • Credit floor
  • Collateral

Link product names to their existing canonical product pages where available. Do not create placeholder destinations.

For small screens, retain the true table and place it in a horizontally scrollable container. Add a subtle visual cue that the table scrolls. Do not convert each product into an accordion because readers need direct column comparison.

Render the short alternatives line after the table. Do not expand it into a directory of unrelated funding products.

I. Straight answers section

This is a long-form objection-handling section and must remain fully open.

Use the writer’s section heading as an H2. Each supplied question or issue becomes an H3 followed immediately by its answer.

Expected topics include:

  • Pros and cons
  • Falling sales and default
  • Credit-score effects
  • Legitimacy and legality
  • Regulation and disclosure
  • Terms to review
  • Choosing a provider
  • Whether the cost is worth it

For pros and cons, two side-by-side lists may be used on desktop and stacked on mobile.

For terms to review, use a real list rather than a dense paragraph.

Do not:

  • Collapse the answers into an accordion.
  • Hide answer text behind “read more.”
  • Put legal and default information in tooltips.
  • turn the section into tabs.
  • soften or remove the writer’s negative points.

If the site’s FAQ component is mandatory, configure every item expanded by default and ensure all answer text is present in server-rendered HTML. A plain H3-and-paragraph layout is preferred.

J. Verified reviews

Use the writer’s reviews heading and the client’s real review data.

Display:

  • Aggregate rating
  • Total review count
  • Review-platform attribution
  • Four to six relevant verified reviews where available
  • Reviewer name in the approved display format
  • Business type
  • Review date
  • Review text

Favor supplied reviews about speed, cost clarity and advisor support. Do not edit review wording beyond approved truncation.

A carousel is acceptable here, with these requirements:

  • No autoplay.
  • Previous and next controls must be keyboard accessible.
  • Controls need descriptive accessible names.
  • Show one card on small screens and two or three on larger screens.
  • Provide visible focus states.
  • If JavaScript fails, reviews should render as a readable stacked list.
  • Keep all review content in the server-rendered document.
  • Do not use reviewer photos unless the site has explicit permission.

If fewer than four approved reviews are available, use a static grid with the available reviews. Never generate filler testimonials.

K. Final CTA

End the page with a full-width CTA banner inside the main content area.

Include:

  1. Final heading
  2. Two-line supplied CTA text
  3. Primary button linking to #mca-application
  4. Published phone number as a tel: link

Restate only the supplied decision and funding times. Do not add false urgency, countdown timers or “limited offer” language.

On mobile, stack the button and phone link and make both at least 44px high.

Part 5Heading hierarchy

Maintain this semantic structure regardless of visual styling:

H1: Page title

H2: Terms at a glance
H2: Definition/how it works
  H3: Percentage-of-sales remittance
  H3: Fixed ACH remittance

H2: Cost
  H3: APR
  H3: Fees
  H3: Early payoff

H2: Qualification
  H3: Credit
  H3: Startups
  H3: Collateral/guarantees

H2: Uses and fit
H2: Application process
H2: Product comparison

H2: Straight answers
  H3: One heading for each visible answer

H2: Reviews
H2: Final CTA

Use the writer’s actual headings rather than replacing them with this wording. This outline controls levels only.

Do not style ordinary paragraphs as headings.

Part 6Design direction

Use the client’s current component library and tokens. The page should feel like part of the live site, not a separate microsite.

Layout

  • Wide container for hero and tables: approximately 1120–1200px maximum.
  • Reading-width container for prose: approximately 700–780px.
  • Use wider content only for two-column layouts and comparison tables.
  • Maintain generous section spacing and clear topic separation.
  • Alternate neutral backgrounds sparingly to distinguish major sections.

Components

Reuse existing:

  • Buttons
  • Form controls
  • Alert and error states
  • Cards
  • Tables
  • Review components
  • Breadcrumbs
  • Phone-link treatment
  • Legal-consent components

Use one dominant primary-button style throughout. Secondary links should not compete with the application CTA.

Avoid

  • Repeated brand or partner logos
  • Generic “Why choose us” sections
  • Oversized decorative statistics
  • Excessive icons
  • Popup forms
  • Autoplay video
  • Auto-rotating testimonials
  • Stock-market or corporate-finance imagery
  • Location or state link grids
  • A lender-ranking section
  • A calculator replacing the written example

Part 7Responsive behavior

Desktop

  • Hero is two columns.
  • Terms table spans beneath both hero columns.
  • Mechanics cards and uses/business-type blocks are side by side.
  • Cost and comparison tables use the wide container.
  • Long explanatory passages use the narrower reading width.

Tablet

  • Hero may remain two columns if the form stays at least 340px wide.
  • Otherwise stack before controls become cramped.
  • Tables may scroll horizontally.

Mobile

  • Use a single column.
  • Put the hero form before the terms table.
  • Stack all paired cards and lists.
  • Preserve table columns inside accessible horizontal scrolling containers.
  • Do not shrink table text below the site’s normal readable body size.
  • Keep all touch targets at least 44×44px.
  • Do not use a sticky CTA that obscures form controls, legal text or table content.

Part 8Form, CTA and phone behavior

All primary application CTAs on this page should point to the one hero form.

For anchor buttons:

  • Use normal anchor behavior so they work without JavaScript.
  • Smooth scrolling may be added if the user has not requested reduced motion.
  • After a keyboard-initiated jump, move focus to the form heading or first field without trapping focus.

Track the CTA’s page position using a non-PII analytics property, such as:

hero
application_steps
final_banner

Phone numbers must:

  • Match the site’s published sales number.
  • Use tel: links.
  • Retain visible formatting.
  • Be trackable without replacing the visible number with an unapproved one.

Part 9SEO implementation

Metadata

Use the supplied SEO title and meta description if present.

If explicit metadata was not supplied:

  • Set the title from the H1 plus the site name using the site’s existing title pattern.
  • Build the meta description from the opening summary without introducing new claims.
  • Keep the canonical URL on the clean MCA route.

Also provide:

  • Self-referencing canonical
  • Open Graph title and description
  • Open Graph URL
  • Existing approved social image or a standard site-branded image
  • robots: index, follow

Do not create near-duplicate URL variants for “MCA,” “cash advance,” cities or states.

Structured data

Preserve the site’s existing Organization, WebSite and breadcrumb schema.

Add a WebPage entity for this URL. A Service entity may identify the service as “Merchant cash advance,” with the existing organization as provider and the United States as the service area.

Do not classify it as LoanOrCredit.

Only include rates, prices or offer properties in structured data when the exact same current information is visibly present on the page.

FAQ schema may be generated for the visible straight-answer entries only when:

  • Each question and complete answer is visible on the page.
  • The schema text exactly matches the page.
  • No answer exists only in markup.
  • The site’s current structured-data policy permits it.

Do not add fabricated review schema. If the site already has an approved review-schema system, the rating and count must exactly match the visible live data.

Part 10Accessibility

Meet WCAG 2.2 AA expectations.

Required checks:

  • One H1 and logical heading order
  • Visible keyboard focus
  • Sufficient color contrast
  • Labels associated with every form control
  • Error messages tied to fields with aria-describedby
  • Error summary receives focus after failed submission
  • Tables use captions and scoped headers
  • Horizontal table containers are keyboard accessible
  • Carousel controls have accessible names
  • No autoplay
  • No information conveyed by color alone
  • Decorative images use empty alt text
  • Meaningful images have accurate alt text
  • Respect prefers-reduced-motion
  • Content remains usable at 200% zoom and 320px viewport width

All important copy must exist in server-rendered HTML.

Part 11Performance

  • Server-render or statically render all primary content.
  • Do not require JavaScript to display answers, tables or reviews.
  • Preload only assets needed above the fold.
  • Give every image explicit width and height.
  • Use modern responsive image formats.
  • Lazy-load images below the fold.
  • Avoid adding a heavy carousel library for the review section; use the site’s existing component or lightweight progressive enhancement.
  • Defer nonessential analytics and third-party review scripts.
  • Keep the form functional if nonessential scripts fail.
  • Prevent layout shift when validation messages or review data load.

Target the site’s current Core Web Vitals thresholds, particularly LCP for the hero and CLS around the form.

Part 12Analytics

Use the site’s existing event system. Recommended events:

mca_page_view
mca_application_start
mca_application_submit
mca_application_success
mca_application_error
mca_cta_click
mca_phone_click
mca_product_link_click

Record only approved, non-PII values such as:

  • CTA location
  • Device category
  • Destination product
  • Form step or error type

Never send names, phone numbers, emails, business names, revenue values or credit information to analytics.

Part 13Pre-publication checks

Content

  • All supplied sections appear in the required order.
  • No substantive answer is collapsed or hidden.
  • There is one H1.
  • MCA is not incorrectly called a loan.
  • Amounts, rates, minimums and timing match approved product data.
  • The worked example’s arithmetic is correct.
  • The same figures are used consistently in the hero, tables, application steps and final CTA.
  • No unresolved tokens or bracketed placeholders remain.
  • State and legal disclosures match approved copy.

Application

  • Every field maps correctly to the lead system.
  • The initial form uses the promised soft-pull process.
  • Consent text and links are current.
  • Validation works with keyboard and screen reader.
  • Failed submissions preserve entered data.
  • Success and error paths have been tested.
  • UTMs and product attribution are retained.
  • No PII reaches analytics.
  • Every application CTA reaches #mca-application.
  • The phone number works on mobile.
  • Product-comparison links use canonical live URLs.
  • Calculator links appear only if the destination exists.
  • Privacy and terms links work.
  • No placeholder or staging URLs remain.

Reviews

  • Rating and count are current.
  • Every displayed review is real and approved.
  • Dates and attribution are visible.
  • Carousel works without autoplay and with keyboard controls.
  • Reviews remain readable without JavaScript.

Technical SEO

  • Page is indexable.
  • Canonical is correct.
  • Metadata is unique.
  • Open Graph data resolves.
  • Structured data validates and matches visible content.
  • No competing MCA page uses the same title, H1 or canonical target.
  • The page is included in the XML sitemap.

Responsive and accessibility

Test at minimum:

  • 320px mobile
  • 375–430px mobile
  • 768px tablet
  • 1024px laptop
  • 1440px desktop
  • 200% zoom
  • Keyboard-only navigation
  • Screen-reader form and table flow

The page is ready only when the application, cost tables, open straight-answer section, reviews and final CTA all function correctly on mobile and desktop.