Delivered remotely for a business based in Geneva, Switzerland. Names withheld by agreement.
Project Overview
Industry: Automotive retail with integrated consumer finance.
Type of solution: A customer-facing web application architected as a presentation and orchestration layer over a separate core business API, delivering the complete browse-to-purchase-to-payment journey.
Business context: Vehicle finance is one of the longest and most abandonment-prone customer journeys in retail. It combines a considered purchase decision with a credit application, identity verification, bank verification and mandatory regulatory disclosures. Every one of those steps is a place where a customer stops. Historically the process was completed in person precisely because it was too complex to do any other way — which meant the business could only sell during opening hours, at the pace of available staff.
General users: Prospective and existing customers browsing vehicles, applying for finance, submitting trade-ins, scheduling appointments and managing payments. A co-borrower can participate as a secondary applicant.
General purpose: To move the complete purchase and finance journey online, at a conversion rate that justifies it, without rebuilding or destabilising the core platform that holds inventory, customer, credit and payment records.
The Business Challenge
A long funnel with mandatory steps. Vehicle finance cannot be shortened arbitrarily — identity verification, bank verification and regulatory disclosures are obligations, not design choices. The journey had to be made tolerable rather than shorter.
Abandonment is the default outcome. Most people who begin a finance application do not finish it in one sitting. A journey that treats an incomplete application as nothing captures no value from the majority of the traffic it attracts.
Customers will not commit before they know their terms. Asking someone to complete a full credit application before showing indicative terms is asking them to accept a credit enquiry with an unknown outcome. Many will not, and the business never learns who they were.
The core system could not be replaced. Inventory, customers, credit decisions and payments live in an existing core platform. That system works and carries the regulatory weight of the business. The new channel had to work with it, not around it or instead of it.
Every operation depends on another system. With the authoritative data held elsewhere, every meaningful action is a remote call that can fail, time out or return something unexpected — and the customer must never see that as a broken page in the middle of a credit application.
Sensitive data passes through. Identity information, bank details and credit data traverse the layer, which sets a security bar considerably above that of an ordinary marketing website.
The storefront has to be found. As the business's public-facing channel, organic search performance is a direct commercial input rather than a marketing extra.
The design would change repeatedly. A consumer storefront in a competitive sector is redesigned often, and each redesign could not be allowed to put the finance journey at risk.
Our Approach
Build a genuine backend-for-frontend, not a second system. The application holds almost no data of its own. Every meaningful operation calls the core platform, and every one of those calls is isolated in a dedicated integration layer. When the core contract changes, one layer changes — not every controller and template that happens to display customer data.
Capture identity before asking for commitment. Rather than treating an incomplete application as nothing, the journey establishes a partial customer record early. An abandoned application becomes a person the business can follow up with, which converts the funnel's largest segment — people who left — from a total loss into a pipeline.
Show terms before requiring a full application. A separate pre-qualification path lets a customer see indicative terms before committing to a complete credit application. This is the single most effective structural change available in vehicle finance, because it inverts the order of trust: the business demonstrates value before asking the customer to accept a credit enquiry.
Design the journey to be resumable. Progress is carried across steps so a customer who leaves and returns is not starting again — the most common reason long applications are abandoned twice.
Treat security as a design requirement of the layer itself. Content Security Policy, CSRF protection with token refresh, cache prevention on authenticated pages, cookie encryption, trusted host and proxy configuration and strong credential rules were built in, because a page handling identity and bank data cannot be secured only by the system behind it.
Validate at the boundary. Password strength, international phone number format and date sanity are enforced as explicit validation rules before data reaches the core system, so bad input is rejected where the customer can still correct it.
Separate presentation from journey logic. The view layer was structured so the storefront could be redesigned repeatedly — through several visual generations — without disturbing the integration or the finance journey underneath.
Make search visibility a feature. Slug-based vehicle URLs and automated sitemap generation were built in, because for a public storefront, discoverability is part of the product.
Containerise the deployment. The current generation builds as a container with front-end assets compiled at image build time, making releases reproducible and horizontally scalable.
The Solution
Vehicle browsing and search. Customers search and filter inventory, save vehicles of interest, and view detail pages built on search-friendly URLs — with all inventory served live from the core platform.
Pre-qualification. A short path gives customers indicative terms before any full application, letting them shop with a realistic budget rather than a guess.
Multi-step finance application. The full application is delivered as distinct stages, each validated and submitted individually, so progress is preserved and a customer is never asked to complete everything in one uninterrupted sitting.
Early partial identity capture. A partial customer record is established early in the journey, so an incomplete application remains a contactable opportunity rather than an anonymous exit.
Co-borrower support. A second applicant can be added, retrieved or removed during the journey, with their own details captured — reflecting how vehicle finance applications are frequently made in practice.
Identity and bank verification. Verification steps are presented within the journey and executed through the core platform, keeping regulated checks inside the flow rather than diverting the customer elsewhere.
Approval disclosures. Regulated disclosures are presented and acknowledged as an explicit step, so the compliance obligation is met within the digital journey rather than deferred to a paper process.
Down payment and cash purchase. Down payment handling within the finance path, and a separate cash purchase route for customers not financing.
Trade-in submission. Customers submit a vehicle for trade-in valuation as part of the purchase journey, so the deposit conversation and the purchase conversation happen together.
Payment setup and management. Payment processing, saved payment methods, payment detail management and automatic payment enrolment — extending the product past the sale into the ongoing relationship.
Warranty presentation. Warranty options presented within the purchase journey.
Appointment scheduling. Calendar-based appointment booking with availability checking, for customers who want to complete or collect in person.
Content and support. Editorial articles, informational pages, FAQs, contact and feedback capture, supporting both customer confidence and organic search performance.
Key Features
Pre-qualification before full application A separate short path showing indicative terms before a full credit application, letting customers shop to a realistic budget without first accepting an unknown outcome.
Early partial identity capture A partial customer record established early in the journey, turning abandoned applications from anonymous exits into contactable opportunities.
Staged, resumable finance application The application is delivered as discrete validated stages with progress preserved, so a customer who leaves can return rather than restart.
Co-borrower participation A second applicant can be added, retrieved or removed mid-journey with their own details, matching how vehicle finance is commonly applied for.
In-journey identity and bank verification Regulated verification steps handled within the flow rather than diverting the customer to a separate process.
Regulated disclosure presentation Approval disclosures presented and acknowledged as an explicit journey step, meeting the compliance obligation digitally.
Trade-in within the purchase flow Trade-in submission integrated into the buying journey, so the deposit and the purchase are handled in one conversation.
Payment management and automatic payments Payment processing, stored payment methods and automatic payment enrolment, extending the product into the post-sale relationship.
Appointment scheduling with availability Calendar-based booking with real availability checking for customers completing or collecting in person.
Search-optimised storefront Slug-based vehicle URLs, automated sitemap generation and editorial content, treating organic discoverability as a product capability.
Technical Architecture
Presentation layer. A server-rendered web application with a view layer structured to support repeated visual redesign, and compiled front-end assets built as part of the container image.
Journey orchestration layer. Controllers coordinate multi-step flows, carrying progress across stages and handling the branching between pre-qualification, full application, cash purchase and trade-in paths.
Integration layer. A dedicated set of functions, each wrapping one core platform operation — customer validation, profile management, co-applicant handling, pre-approval, the staged application submissions, partial customer creation and error forwarding. This is the application's architectural centre: all knowledge of the core platform's contract lives here and nowhere else.
Validation layer. Explicit custom rules for credential strength, international phone number format and date validity, applied at the boundary before data is forwarded to the core system.
Security layer. Content Security Policy defined as a custom policy class, CSRF protection with token refresh, cookie encryption, cache-prevention middleware on authenticated pages, custom authentication checking, and trusted host and proxy configuration.
Core platform. A separate system of record holding inventory, customers, credit decisions, verification outcomes and payments — reached exclusively through the integration layer.
Observability. Error and performance monitoring in production, with integration failures also forwarded to the core platform so the team owning the API sees problems in their own system.
Deployment. Containerised builds with dependency installation and asset compilation performed at image build time, producing reproducible, horizontally scalable deployment units.
Flow: Browser → Server-rendered presentation layer → Journey orchestration (session-carried progress) → Integration layer → Core platform API (inventory, customer, credit, verification, payments) → Monitoring & error forwarding
Technology Stack
| Category | Technology |
|---|---|
| Language | PHP |
| Framework | Laravel |
| Templating | Blade, with multiple co-existing theme generations |
| Core integration | HTTP/cURL calls to a separate core business API through a dedicated helper layer |
| Authentication | Laravel Sanctum with custom authentication middleware |
| Security | Content Security Policy (custom policy class), CSRF with token refresh, cookie encryption, cache-prevention middleware, trusted host and proxy configuration |
| Validation | Custom rules for password strength, international phone numbers and date validity |
| Phone handling | libphonenumber for PHP |
| SEO | Automated sitemap generation, slug-based URLs |
| Monitoring | Sentry, plus log viewer and error forwarding to the core platform |
| Containerisation | Docker with a custom base image and in-image asset build |
| Deployment | Container-based deployment, with Capistrano tooling retained |
| Testing | PHPUnit, Faker, Mockery |
Technical Challenges & Solutions
| Challenge | Our Approach |
|---|---|
| A long, regulated funnel with high abandonment | The journey was restructured rather than shortened: pre-qualification before full application, discrete resumable stages, and early partial identity capture so incomplete applications remain contactable opportunities. |
| Customers unwilling to complete a credit application before knowing their terms | A separate pre-qualification path providing indicative terms first, inverting the order of trust so the business demonstrates value before requesting a full credit enquiry. |
| The system of record could not be replaced or destabilised | A genuine backend-for-frontend: the application holds almost no data, and every core operation is isolated in one integration layer, so a modern channel was delivered without altering the platform carrying the business's regulatory weight. |
| Every meaningful operation depending on a remote system | All core calls centralised in one layer with consistent error handling and failure forwarding, so integration problems are handled uniformly and surfaced to the team that owns the API rather than only logged locally. |
| Identity and bank data passing through a public web layer | Security treated as a property of this layer in its own right — content security policy, CSRF with token refresh, encrypted cookies, cache prevention on authenticated pages, and boundary validation of credentials and contact data. |
| Applications commonly involving two people | Explicit co-borrower support with add, retrieve and remove operations mid-journey, rather than forcing a single-applicant model onto a two-applicant reality. |
| Repeated storefront redesign without risking the finance journey | View generations kept separate from journey orchestration and integration logic, so the storefront could be visually rebuilt several times while the functional core remained untouched. |
| Organic search as a commercial requirement | Slug-based vehicle URLs and automated sitemap generation built in, with editorial content supporting both customer confidence and discoverability. |
| Reproducible, scalable deployment of a nearly stateless application | Containerised builds with dependencies and assets compiled into the image, so instances are identical and can be scaled horizontally behind a load balancer. |
Security & Reliability
Content Security Policy. An explicit, code-defined policy constraining what the page may load and execute — a meaningful protection for a page collecting identity and financial information.
Request integrity. CSRF protection with token refresh support, so long-lived journey pages remain protected without failing legitimate submissions.
Session and cookie protection. Encrypted cookies with trusted host and proxy configuration appropriate to a load-balanced deployment.
Cache prevention on authenticated pages. Sensitive finance pages are prevented from being retrievable through browser history or intermediate caches.
Boundary validation. Password strength, international phone number format and date validity enforced before data reaches the core platform, so invalid input is rejected where the customer can still act on it.
Data minimisation by architecture. Because the application is a presentation layer rather than a system of record, sensitive data is not accumulated locally — it is passed through to the platform designed to hold it.
Failure visibility. Production error monitoring combined with forwarding of integration failures to the core platform, so problems are visible to the team able to act on them.
Reproducible deployment. Containerised builds ensure that what is tested is what runs, and that recovery means starting another identical instance.
Scalability & Performance
A nearly stateless application tier. With the authoritative data held by the core platform, instances carry little state and scale horizontally by running more containers.
Build-time asset compilation. Front-end assets are compiled into the image, so no build work happens at runtime and every instance serves identical, optimised assets.
Appropriate cache control per page type. Public storefront pages and authenticated finance pages are given different cache treatment, balancing performance against the confidentiality of the latter.
Thin local data footprint. Minimal local persistence means very little database load, keeping the layer's own resource profile small.
Centralised integration. With all core calls in one layer, timeout, retry and error behaviour is consistent and can be tuned in a single place as the core platform's characteristics change.
Search-efficient URLs. Slug-based, cacheable public URLs support both discoverability and edge caching of the public catalogue.
Business Outcomes
- The complete purchase and finance journey is available online, no longer constrained to opening hours or staff availability.
- Customers can see indicative terms before committing to a full credit application, removing the largest barrier at the top of the funnel.
- Abandoned applications became follow-up opportunities, because partial identity is captured before the customer leaves.
- Applications are resumable, so a customer who steps away does not have to start over.
- Two-applicant households are supported properly, with co-borrower participation built into the journey.
- Regulated steps happen inside the digital flow, with verification and disclosures presented in-journey rather than diverting the customer to a separate process.
- The relationship continues past the sale, through payment management and automatic payment enrolment.
- The core platform was never put at risk, because the new channel was delivered as a layer over it rather than a replacement for it.
- The storefront can be redesigned freely, since presentation is separated from journey and integration logic.
Why it worked
There are two ways to give a business a modern digital channel. One is to rebuild the core system, which is expensive, slow and — where that system carries regulatory weight — genuinely risky. The other is to build a properly designed layer over it. The second is usually right, and it is frequently done badly: teams scatter integration calls throughout controllers and templates, and the result is a front end welded to a contract it does not control.
Our team builds that layer with discipline. All knowledge of the core platform lives in one integration layer, so contract changes are absorbed in one place. Validation happens at the boundary, where the customer can still fix their input. Security is designed as a property of the layer itself, because a page collecting bank and identity details cannot rely on the system behind it for protection. And presentation is kept separate from journey logic, so the storefront can be redesigned as often as the market requires without anyone touching the finance flow.
We also bring the funnel thinking that determines whether this kind of project pays for itself. Pre-qualification before full application, partial identity capture before abandonment, resumable staged journeys and co-applicant support are not technical details — they are the difference between a digital channel that converts and one that simply exists.
Final Summary
Vehicle finance is one of the hardest journeys to move online. It is long, it is regulated, it involves identity and bank verification, it frequently involves two applicants, and every additional step is somewhere a customer stops. For most of its history it stayed in the dealership for exactly that reason — which limited the business to selling when its doors were open and its staff were free.
Our team built a customer-facing application that delivers the entire journey digitally: browsing and search, pre-qualification showing indicative terms before any full application, a staged and resumable credit application with co-borrower support, identity and bank verification, regulated disclosures, trade-in submission, down payment, appointment scheduling, and payment management including automatic payments after the sale. Early partial identity capture means the customers who leave — always the majority — become people the business can contact rather than anonymous exits.
Architecturally it was built as a presentation and orchestration layer over the client's existing core platform, with every core operation isolated in a single integration layer. That decision delivered a modern channel without touching the system holding inventory, customer, credit and payment records, and left the storefront free to be redesigned repeatedly without the finance journey being disturbed. Combined with a security posture built for a page that handles identity and bank data, and containerised deployment for reproducible horizontal scaling, it is the pattern that lets an established regulated business modernise its front door without rebuilding the house.