Delivered remotely for a business based in Utrecht, Netherlands. Names withheld by agreement.
Project Overview
Industry: Consumer finance — loan servicing and payment collection.
Type of solution: A customer-facing web portal built as a presentation and orchestration layer over an existing core lending platform, holding no loan data of its own.
Business context: Loan servicing costs scale with the size of the book, and almost none of that cost is discretionary. Borrowers call to check balances, confirm due dates, make payments and update payment details, and every one of those calls occupies a person. The commercial case for self-service is usually made on cost, but the more significant effect is on collections: a payment that is easy to make is a payment that gets made, and a borrower who can see their schedule at 11pm is less likely to miss it.
General users: Borrowers servicing an existing loan. Lender staff continue to operate in the core platform.
General purpose: To handle the routine servicing interactions without a phone call, without duplicating loan data into another system, and without expanding the organisation's card-data footprint.
The Business Challenge
High volumes of low-value contact. The most common reasons borrowers call a lender are also the most mechanical. Handling them by phone is expensive, slow for the borrower, and adds nothing.
Payments must be effortless. Friction in a payment path converts directly into missed payments, which cost far more than the servicing calls do. Anything that makes paying harder is a collections problem, not a usability one.
Card data expands regulatory scope. The obvious way to build a payment portal — collect card details on your own form and pass them to a processor — pulls the entire web application into card-data compliance scope. That is a permanent cost and a permanent risk.
The core system holds the truth. Balances, schedules and payment history live in the core lending platform. Duplicating them into a portal creates reconciliation risk, and in a regulated context, showing a borrower a figure that differs from the system of record is a serious problem.
Nothing may fail ambiguously. In a payment flow, an unclear outcome is worse than a clear failure. A borrower who cannot tell whether their payment was taken will call — which defeats the portal's purpose — or pay twice, which is worse.
Legal presentation is mandatory. A regulated consumer lender must make terms, privacy policy and user agreements available and current.
Our Approach
Keep card data out of the web layer entirely. Rather than building payment forms locally, the portal requests the payment form from the core platform and presents it. Card details are handled by the system already equipped and certified for that purpose. This is the decision that determines the portal's compliance footprint, and it was made at the outset rather than discovered later.
Hold no loan data locally. The application has effectively no local schema. Balances, schedules and dates are retrieved from the core platform for display and not stored, so the portal can never show a figure the system of record does not agree with — and there is no duplicated financial data to protect or reconcile.
Manage the API session properly. Authentication against the core platform uses a token lifecycle with expiry tracking, a validity check before each call and refresh when needed — rather than re-authenticating on every request or letting a token expire mid-payment.
Translate integration responses into human language. Core platform response codes are mapped into consistent user-facing messaging, so a borrower sees an explanation they can act on rather than an integration error they cannot.
Keep the surface small and make it faultless. This is a product where a handful of flows carry all the value. The scope was kept deliberately narrow so those flows could be built and verified properly.
Treat legal content as product. Terms, privacy policy and user agreement were built as first-class routes rather than static afterthoughts, so a regulated lender's obligations are met and maintainable.
Apply security appropriate to a payment context. Content Security Policy and origin controls were configured for a page that sits inside a payment journey.
The Solution
Borrower sign-in. Customers authenticate against the core platform, with the portal holding session state and managing the API token lifecycle behind the scenes.
Loan dashboard. A borrower sees their loan information — balance, key dates and status — retrieved live from the core system, so what the portal shows and what the lender's staff see are always the same.
Payment schedule. The full schedule of upcoming payments and their dates, so borrowers can plan rather than call to ask.
Make a payment. Borrowers pay directly through the portal, selecting a payment method and completing payment through a form served by the core platform — so the transaction is executed by the system that owns it, and card details never touch the web layer.
Payment method selection. Where more than one method is available, borrowers choose how they wish to pay before proceeding.
Scheduled payments. Future and recurring payments are arranged through a scheduling form retrieved from the core system, keeping the authorisation with the platform that will execute it.
Account settings. Borrowers manage their own account details rather than calling to have them changed.
Support content. FAQs and contact capture, addressing the questions that would otherwise become calls and giving a clear route through when a genuine query remains.
Legal documents. Terms and conditions, privacy policy and user agreement presented as maintained, accessible pages.
Key Features
Payment execution without card data in the web tier Payment forms are served by the core platform and presented by the portal, so card details are handled by the system certified for them — keeping the web application out of card-data compliance scope.
Live loan data with no local duplication Balances, dates and schedules are retrieved from the core system for display and never stored, eliminating reconciliation risk and ensuring the borrower and the lender always see the same figures.
Full payment schedule visibility Upcoming payments and dates presented clearly, so borrowers can plan without contacting the lender.
Scheduled and recurring payments Future payment arrangements made through the core system's own scheduling form, keeping authorisation with the platform that will execute it.
Managed API token lifecycle Token acquisition, expiry tracking, validity checking and refresh handled transparently, so sessions do not fail in the middle of a payment.
Human-readable error handling Core platform response codes translated into consistent, actionable user messaging rather than surfacing raw integration failures.
Self-service account management Borrowers update their own account details, removing another common reason for contact.
Maintained legal documentation Terms, privacy policy and user agreement as first-class, maintainable pages meeting a regulated lender's presentation obligations.
Technical Architecture
Presentation layer. A server-rendered web application with a view layer structured to support redesign independently of the underlying integration.
Orchestration layer. Controllers coordinating the borrower's journey — authentication, dashboard, schedule, payment and account management — composing data retrieved from the core platform.
Integration layer. A dedicated set of functions, each wrapping one core platform operation: customer validation and information retrieval, loan data and dates, payment form retrieval, scheduling form retrieval, and the authentication token lifecycle. All knowledge of the core contract lives here.
Session and token layer. Borrower session state alongside the core API access token, refresh token and expiry, with validity checked before calls and refresh performed transparently.
Response handling layer. Structured mapping of core response codes into consistent user-facing notification and validation messaging.
Core platform. The system of record holding loans, balances, schedules, payment history and payment execution — reached exclusively through the integration layer.
Security layer. Content Security Policy and cross-origin controls configured for a page operating within a payment journey.
Flow: Browser → Portal presentation layer → Orchestration → Integration layer (token-managed) → Core lending platform (loan data, payment and scheduling forms) → Payment executed by the core platform, not the portal
Technology Stack
| Category | Technology |
|---|---|
| Language | PHP |
| Framework | Laravel |
| Templating | Blade, with co-existing theme generations |
| Core integration | HTTP/cURL calls to a core lending API through a dedicated helper layer |
| API authentication | Token lifecycle with expiry tracking and refresh against the core platform |
| Session handling | Laravel Sanctum |
| Security | Content Security Policy, cross-origin controls |
| HTTP client | Guzzle |
| Testing | PHPUnit, Faker, Mockery |
Technical Challenges & Solutions
| Challenge | Our Approach |
|---|---|
| A payment portal expanding the organisation's card-data compliance scope | Payment and scheduling forms are retrieved from the core platform and presented by the portal, so card details are captured and processed by the system already equipped for them. The web layer never handles card data — the decision that defines the portal's entire compliance position. |
| Showing borrowers figures that must match the system of record exactly | No loan data is stored locally. Balances, dates and schedules are retrieved live for display, so the portal cannot drift from the core system and there is no duplicated financial data to reconcile or protect. |
| Authentication tokens expiring mid-journey | An explicit token lifecycle with expiry tracking, pre-call validity checking and transparent refresh, so a borrower is never dropped in the middle of a payment because a token aged out. |
| Integration failures surfacing as incomprehensible errors | Core response codes mapped into consistent, human-readable user messaging, so a borrower sees something they can act on rather than a raw failure — particularly important in a payment flow, where confusion generates the phone call the portal exists to prevent. |
| Recurring payment authorisation spanning two systems | Scheduling handled through the core system's own form, so the authorisation is held by the platform that will actually execute the payments rather than being mirrored across systems. |
| A small surface carrying all the value | Scope deliberately kept narrow so the handful of flows that matter — view, pay, schedule — could be built and verified thoroughly rather than adequately. |
| Regulated content that must be present and current | Legal documents implemented as first-class routes with maintained content rather than static files, so obligations are met and updates are straightforward. |
Security & Reliability
Compliance scope reduction by design. Card details are never collected or transmitted by the web application. Payment forms come from the core platform, which executes the transaction — the most effective security control available to a portal of this kind, because it removes the risk rather than mitigating it.
No local financial data. Loan balances, schedules and payment history are not stored in the portal, so a compromise of the web tier does not expose a borrower's financial position.
Managed authentication lifecycle. Access and refresh tokens are tracked with expiry and validated before use, so authorisation is current at the point each core call is made.
Content Security Policy. An explicit policy constraining what the page may load and execute, appropriate for a page in a payment journey.
Cross-origin controls. Explicit policy governing which origins may interact with the application.
Clear failure semantics. Response codes are mapped deliberately, so ambiguous outcomes are minimised in exactly the flow where ambiguity is most costly.
Regulated content availability. Terms, privacy policy and user agreement maintained as accessible pages.
Scalability & Performance
Near-stateless application tier. With no meaningful local data, instances can be scaled horizontally behind a load balancer with externalised session storage.
Minimal local processing. The portal composes and renders rather than computing, so its own resource footprint is very small; page latency is dominated by core platform response times.
Token reuse. Authentication tokens are reused across requests within their validity window rather than re-acquired per call, removing an unnecessary round trip from every operation.
Centralised integration. With all core calls in one layer, timeout and retry behaviour can be tuned in a single place as the core platform's characteristics change.
Narrow surface. A small, focused application is fast to deploy, quick to start and simple to reason about under load.
Business Outcomes
- The most common servicing interactions no longer require a call, because balances, schedules and payments are available directly to the borrower.
- Paying is easy and available at any hour, which affects collections performance rather than only convenience.
- The organisation's card-data footprint did not expand, because payment capture stayed with the system already equipped for it.
- Borrowers and staff always see the same figures, since nothing is duplicated into the portal.
- Recurring payments can be arranged by the borrower, reducing both missed payments and the calls that follow them.
- Account changes are self-service, removing another routine contact reason.
- The core lending platform was untouched, so a new customer channel was delivered without altering the system carrying the business's regulatory weight.
- Legal obligations are met digitally, with maintained terms, privacy and agreement content.
Why it worked
The instinct in a payment portal project is to build the payment form. It is the obvious feature, and building it is how organisations quietly pull an entire web application into card-data compliance scope — a permanent cost and a permanent liability, discovered during the first audit rather than during design.
Our team makes that call the other way round, at the start. Where a core platform can serve the payment form, the portal presents it rather than replacing it, and the web tier stays outside the compliance boundary. We apply the same reasoning to data: a servicing portal should hold no loan data at all, because duplicated financial figures create reconciliation risk and give an attacker something to find. Nothing stored is nothing to reconcile and nothing to leak.
We also pay attention to the parts of a payment flow that determine whether it is trusted — token lifecycles that do not expire mid-journey, response codes translated into language a borrower can act on, and failure semantics that are clear rather than ambiguous. In loan servicing, an uncertain outcome produces the phone call the portal was built to prevent, and a payment made twice. Getting those details right is what makes a small application genuinely valuable.
Final Summary
A lender's servicing operation absorbs a continuous volume of routine contact: balance enquiries, due date confirmations, payments and card updates. Each is mechanical, each occupies a person, and none of them generate revenue. The cost case for self-service is straightforward — but the more important effect is on collections, because a payment that is easy to make at any hour is a payment more likely to be made at all.
Our team built a borrower portal covering precisely those interactions: loan and balance visibility, full payment schedule, payments, payment method selection, scheduled and recurring payments, and self-service account management, alongside the FAQ, contact and legal content a regulated consumer lender must provide.
The architecture is what makes it durable. The portal holds no loan data — everything is retrieved live from the core lending platform, so borrower and lender always see identical figures and no financial data is duplicated into a web-facing system. Payment and scheduling forms are served by the core platform and presented by the portal, so card details never enter the web tier and the organisation's compliance footprint does not expand. Authentication runs on a managed token lifecycle that will not expire mid-payment, and core response codes are translated into messaging a borrower can act on. Small, focused and deliberately thin, it delivers a new customer channel without touching the system of record behind it.