When I took on the customization work for AutoContentment, a car listing platform built on Laravel, one of the most requested features from the client was simple to describe but genuinely tricky to execute well: a VIN (Vehicle Identification Number) checker that buyers could pay to use before committing to a car purchase. On paper, it sounds like a straightforward "enter a number, get a report" feature. In practice, it touches billing, third-party API reliability, user trust, and security all at once. This post walks through how I approached it, the decisions I made, and the lessons I picked up along the way.
Why a VIN Checker Matters on a Car Listing Platform
If you've ever bought a used car, you know the anxiety of not knowing the full history of the vehicle. Has it been in an accident? Does it have outstanding liens? Is the mileage on the odometer legitimate? A VIN check answers these questions by pulling historical records tied to the vehicle's unique identifier.
For a platform like AutoContentment, offering this as a built-in, paid feature does two things. First, it builds trust with buyers, who now have a reason to complete their research directly on the platform instead of bouncing to a third-party site. Second, it opens a monetization channel that doesn't depend on listing fees or ads. Every VIN check purchased is direct revenue, and it ties naturally into the existing user flow: someone browsing a listing is exactly the person who wants to verify that listing.
Planning the Feature Before Writing Code
Before touching the codebase, I mapped out the full user journey:
- A buyer views a car listing.
- They click "Run VIN Check" on the listing page.
- If they haven't paid, they're prompted to pay a small fee via Paystack.
- Once payment is confirmed, the system triggers a request to the VIN lookup API.
- The report is generated and displayed, and a copy is saved to the user's account so they can revisit it without paying again.
This sequence sounds simple, but each step has failure points that needed handling. What happens if payment succeeds but the VIN API times out? What if the buyer refreshes the page mid-transaction? What if the same VIN is checked by multiple users, should we cache results to avoid paying for duplicate lookups from the third-party provider? These questions shaped the database schema and the queue logic long before I wrote a single controller method.
Database Design for VIN Requests
I created a dedicated vin_checks table rather than bolting the feature onto the existing listings table. Each row stored the VIN itself, the requesting user's ID, the payment reference from Paystack, the raw API response, a processed/human-readable version of the report, and a status column (pending, paid, completed, failed).
Separating raw and processed data mattered more than I initially expected. Third-party VIN APIs often return dense, inconsistent JSON structures depending on the vehicle's make, year, and region. Storing the raw response meant that if I needed to reformat how reports were displayed later, I could reprocess historical data without hitting the external API again and incurring additional cost.
The caching layer built on top of this table turned out to be one of the more valuable architectural decisions. If a VIN had already been checked by any user within a reasonable time window, say 30 days, a new request for the same VIN would serve the cached report instantly instead of triggering a new paid API call. This protected margins on the feature and made repeat lookups feel instant for users.
Integrating Paystack
Paystack is the payment processor of choice for most Nigerian platforms, and integrating it into the VIN checker flow was mostly straightforward thanks to their well-documented API. The part that required real care was making sure payment verification and feature unlocking were tightly coupled and tamper-resistant.
I used Paystack's inline JS popup for the checkout experience, since it keeps buyers on the same page rather than redirecting them away from the listing they're viewing. On the backend, I never trusted the frontend's claim that payment succeeded. Every transaction reference returned by Paystack was independently verified server-side against Paystack's verify endpoint before the VIN check was marked as paid and the lookup was triggered. This is a basic but critical security principle: client-side success messages can be spoofed, so the source of truth always has to be a server-to-server check.
I also set up a webhook listener as a backup verification path. If a user closed their browser right after payment but before the frontend could confirm success, the webhook would still catch the successful transaction and unlock the report asynchronously. Without this, some buyers would have paid and never received their report, which is exactly the kind of trust-breaking bug that kills a monetized feature.
Handling the External VIN API
The VIN lookup itself depended on a third-party provider, and third-party APIs are never as reliable as documentation suggests. I wrapped every call in a queued job rather than making it a synchronous part of the request-response cycle. This meant that once payment was confirmed, a job was dispatched to fetch the VIN data, with retry logic and exponential backoff in case the provider's API was temporarily down or rate-limited.
The frontend polled a status endpoint every few seconds while the job ran, and once the report was marked complete, the page updated automatically. This kept the experience responsive even though the actual data fetch happened in the background, and it meant a slow or flaky third-party API didn't translate into a frozen page or a failed request the user would blame on the platform itself.
Security Considerations
Because this feature involved both money and a paid API with a real cost per call, I hardened it against abuse. Rate limiting was applied per user and per IP to prevent someone from spamming VIN check requests to probe for free reports or to stress-test the payment flow. I also validated VIN format server-side before allowing a payment attempt, since a malformed VIN would waste an API call even if the format checks on the frontend were bypassed.
Logging was another priority. Every payment verification attempt, every API call to the VIN provider, and every status transition on a vin_checks record was logged with enough context to debug issues without exposing sensitive payment data in plain logs.
What I'd Do Differently
Looking back, I'd introduce automated tests earlier in this feature's lifecycle. Because it touched an external payment gateway and an external data provider, I initially tested most of the flow manually, which was slow and occasionally missed edge cases like double-webhook delivery from Paystack. Mocking both providers and writing feature tests around the queued job logic would have caught a few bugs before they reached production.
I'd also build the caching logic in from day one instead of adding it after noticing repeat VIN lookups eating into margins. It's a good reminder that even a "simple" paid feature benefits from thinking about cost efficiency at the data layer, not just the user experience layer.
In Conclusion
The VIN checker ended up being a small feature in terms of UI footprint, just a button and a report page, but a substantial one in terms of the systems it touched: payments, queues, third-party reliability, caching, and security. It's a good example of how "simple" client requests often hide real architectural decisions underneath, and why planning the full data and error flow before writing code saves far more time than it costs.
If you're building something similar, a paid data-lookup feature backed by an external API, my biggest recommendation is this: separate the payment confirmation from the data fetch, never let the frontend be the source of truth for payment success, and cache aggressively wherever the underlying data doesn't change often. Those three decisions alone will save you from most of the headaches I ran into.