Krenno
All projectsCase study
Web AppFintech2024web

PayLink

Turn every collector into a controlled, shareable checkout — without giving away the keys to the merchant account.

A dedicated payment link for every collector, with master control over every charge.

View on GitHub

Client

Krenno Labs

Engagement

first party

Krenno roleProduct strategyInformation architectureUX and interface designFull-stack engineering+3 more
Positioning

Why this product exists

Organizations that accept payments through a network of users need more than a single checkout page. They need a unique link for each person, a merchant directory behind that link, and a master console that decides who can charge, how much they can take, which cards are accepted, and whether 3-D Secure is required. PayLink delivers that operating model as a finished product: PCI-aware hosted checkout on one side, and a full administration surface for businesses, users, BIN policy, and platform status on the other.

This project proves Krenno can design and ship a PCI-aware payments product with two equally serious surfaces: a public checkout that feels trustworthy, and an operations console that gives a master operator precise control over every collector, merchant, card rule, and limit. It shows we can integrate a production payment gateway, isolate credentials per user-business relationship, enforce risk policy at the BIN level, and still present a coherent product rather than a pile of screens. For the next client, that means Krenno can take a payments idea and turn it into a gated, scalable digital product with real architecture behind it.

Built for

  • Payment operations teams that manage many collectors under one organization
  • Multi-merchant businesses that route charges through more than one NMI-compatible gateway account
  • Finance and collections managers who need per-user spend limits and card acceptance policy
  • Platform operators who must issue, share, and revoke payment links without exposing secret credentials
  • Product and engineering leaders evaluating a partner that can ship gated fintech workflows
The story

Challenge, approach, solution

01

The Challenge

Card collection at organizational scale is rarely one merchant and one form. A business may operate several gateway accounts. Many people may be authorized to accept money. Each of those people needs a link they can send, and the organization still has to decide which cards are allowed, how much can be charged in a day, whether billing details and 3-D Secure are required, and how to shut the rails down if something is wrong. A generic checkout cannot carry that policy. A spreadsheet of gateway keys cannot either. The product opportunity is a controlled network of payment links with a master operator at the center.

02

Our Approach

We modeled the domain as three connected records: businesses that own gateway destinations and daily capacity, users who each receive a public payment URL, and a payment-method relationship that binds one user to one business with its own tokens, limits, card brands, BIN policy, and 3-D Secure setting. The public experience is a focused checkout. The private experience is a command center for creating those relationships, sharing links, and watching volume. Card data stays inside Network Merchants hosted fields. The application only ever handles tokens, policy, and confirmed results.

03

The Solution

PayLink is the operating system for that model. Operators sign in, register merchant businesses, enroll users, and subscribe each user to the businesses they may collect for. The platform generates a username-based URL that can be copied or shared immediately. A payer who opens the link selects a business, optionally schedules a future charge, enters card details in tokenized fields, and completes an approved sale or subscription. Successful requests update daily and lifetime totals on both the user relationship and the business, so remaining capacity is always visible on the next checkout. If the organization needs a pause, maintenance mode replaces public checkout with a controlled downtime experience and a custom operator message.

Experience

The Experience

A master operator signs in to a protected console, adds a business with its gateway post URL and daily ceiling, then creates a user and assigns that user to one or more businesses. For each assignment they set whether transactions are live, whether billing details and 3-D Secure are required, which card brands are accepted, which six-digit BINs are allowed or blocked, the daily user limit, and the public, secret, and 3-D Secure tokens for that relationship. The console shows the generated payment URL with copy and native share actions, plus a relationship table of limits, current daily value, and lifetime volume. The operator sends the link. The payer lands on a focused secure-payment screen, chooses the business, optionally picks a charge date for a single scheduled payment, and pays with Visa, Mastercard, American Express, or Discover as policy allows. Allowed brands and remaining limit are visible before submit. If 3-D Secure is on, a verification modal completes the bank challenge. Approval routes to a confirmation page that displays the transaction id or subscription id. The same operator can later disable a user, disable a business, tighten BIN policy, or place the entire site into maintenance without touching gateway dashboards.

Product

What we built into the product

Personalized payment links

Every user receives a stable, username-based checkout URL that operators can open, copy, or share. Collectors send one link; payers never need an account.

Master operations console

A protected administration surface for the people who run the network: dashboard identity, business directory, user directory, master BIN list, and platform settings.

Multi-business merchant directory

Operators register each merchant account with a display name, NMI-compatible transaction post URL, daily capacity, and a transaction enable switch. One organization can route volume across many gateway destinations.

User-to-business assignment

A user is subscribed to the businesses they are allowed to collect for. The public link then presents those businesses as a checkout destination rather than a generic pay-anyone form.

Per-relationship payment rules

Each user-business pair carries its own public token, secret token, 3-D Secure token, card-brand policy, BIN policy, billing requirement, transaction switch, and daily limit. Credentials and policy stay isolated to that relationship.

PCI-aware hosted card capture

Card number, expiry, and CVV render in Network Merchants Collect.js hosted fields with inline brand preview. The application receives a payment token, never the raw primary account number.

3-D Secure checkout

When a relationship requires 3-D Secure, the checkout collects billing context, runs Gateway.js authentication, presents a challenge modal, and forwards CAVV, ECI, directory server, and related authentication fields with the charge.

Immediate and scheduled charges

Payers can complete a same-session sale or schedule a single future charge on a chosen date. Scheduled requests use the gateway subscription contract with a monthly cycle and one planned payment.

Dual-layer spending limits

Checkout computes remaining capacity from the tighter of the user's daily relationship limit and the business daily limit. Amounts cannot exceed what is left, and approved sales update both daily and lifetime totals.

Card brand policy

Operators allow Visa, Mastercard, American Express, and Discover independently per relationship. The checkout displays accepted brands and rejects a tokenized card that falls outside policy.

Master BIN allowlists and blocklists

A central six-digit BIN directory, with automatic brand detection, is assigned per card type as an allowlist or a blocklist. Checkout compares the tokenized BIN before the charge is sent.

Transaction kill switches

Operators can disable charges on a single user-business relationship, on an entire business, or both. The checkout refuses the destination when either switch is off.

Gateway credential isolation

Public tokenization keys load in the browser. Secret keys and the static originating IP are applied only on the server when the charge is posted to the merchant gateway.

Also included

Optional billing capture

A relationship can require name, address, city, state, postal code, and country — and email plus structured country and state selectors when 3-D Secure is enabled — before a charge is accepted.

Live volume visibility

User and business records show daily limits, daily value taken, and lifetime value, so operators can see capacity and throughput without leaving the console.

Link sharing and clipboard actions

Each user card exposes the payment URL with one-click copy and native device share, so operators can distribute links from desktop or mobile without extra tools.

Platform maintenance mode

Operators can place public checkout into a downtime state, publish a custom notification, and keep the rest of the organization informed from a single settings screen.

Secure operator authentication

Email and password sessions, show-or-hide password controls, forgot-password recovery, expiry-aware reset, and logout are built on Appwrite account services behind protected admin routes.

Payment confirmation records

Approved immediate charges and scheduled payments land on a confirmation page that presents the gateway transaction id or subscription id as a durable reference.

Responsive operations and checkout

The admin directory uses desktop relationship tables and stacked mobile cards. Checkout, 3-D Secure, login, and settings are designed for phone and desktop without a second codebase.

Gallery

Product surfaces

Visual placeholders mark where final screens and captures will live. Drop assets at the paths shown on each tile.

Operator console. Authenticated administration for profile, businesses, users, master BIN policy, and platform settings.

User and business management. Create, edit, and remove users and merchant businesses, including per-relationship payment rules and live volume.

Public payment link. Username-addressed checkout at /users/{username} with business selection, optional scheduling, and tokenized card capture.

3-D Secure challenge. In-flow bank verification modal mounted on the Network Merchants Gateway.js interface.

Confirmation. Success state that records the gateway transaction id or scheduled-payment subscription id.

Platform controls. Maintenance mode, custom operator messaging, password recovery, and session logout.

Engineering

How it's built

A payer or operator hits a Next.js App Router surface. Public routes resolve a username to a user document, load subscribed businesses, and wait for a business selection before injecting Collect.js with that relationship's public tokenization key. Protected routes require an Appwrite session, then hydrate business and user lists for the console. All writes to Appwrite collections travel through first-party /api/v1/appwrite_db handlers. All charges travel through /api/v1/payments handlers: the browser sends a token and amount; the server loads the saved payment method, attaches the secret key and static IP, posts application/x-www-form-urlencoded fields to the business gateway URL, parses the gateway query-string response, and on approval increments daily and lifetime totals on both the relationship and the business. Scheduled payments follow the same broker pattern with NMI add_subscription fields. 3-D Secure paths add authentication results before the post. A global admin-controls document can replace public checkout with a maintenance experience without redeploying the app.

API-drivenmodularsecure authenticationmulti-entityPCI-aware tokenizationgateway-broker

Decision

Keep raw card data out of the application by using Collect.js hosted fields and payment tokens.

A first-party card form would pull the product into full PCI cardholder-data scope and create an unacceptable storage and logging risk.

The product can offer a branded checkout while the gateway remains the only party that sees the primary account number.

Decision

Model policy as a saved payment method that joins one user to one business.

Tokens, limits, brands, and 3-D Secure are not properties of a user alone or a business alone. They belong to the relationship.

The same collector can accept Visa on one merchant account and a tighter BIN list on another without conflicting configuration.

Decision

Broker every charge through Next.js route handlers instead of posting from the browser to the gateway.

Secret keys, static IP, and ledger updates after approval must be authoritative and invisible to the payer.

Operators can trust that volume counters and remaining limits move only after the gateway reports approval.

Stack

PayLink is a TypeScript Next.js application with an App Router frontend, a first-party API layer that brokers every charge, and Appwrite for authentication and document storage. The stack is chosen so a single deployment can serve a public checkout, a protected operations console, and PCI-safe talks with an NMI-compatible gateway — without the product ever holding raw card numbers.

Next.js 14 App RouterReact 18TypeScriptTailwind CSS and DaisyUIDelius via next/fontNext.js Route HandlersAppwrite Account and Databases SDKAppwrite DatabasesNode.js 20 runtimeAppwrite project platformAppwrite email sessions and recoveryNMI Collect.js tokenization3-D Secure authenticationServer-side secret and IP handlingProtected admin route groupNetwork Merchants (NMI) Collect.js and Gateway.jsNMI-compatible transaction gatewaycountry-state-city
Process

From brief to shipped product

  1. 01Discovery

    We mapped the real operating model: a master manager, many collectors, many merchant accounts, and a payer who should only ever see a focused checkout. That produced the user, business, and relationship records, plus the requirement that secret credentials never appear on the public link.

  2. 02Design

    We split the product into two visual systems that still feel like one brand: a compact indigo checkout card for payers, and a denser DaisyUI operations console for directories, relationship tables, and policy toggles. Mobile stacks and desktop tables were designed together so volume and BIN policy remain readable on both.

  3. 03Development

    We implemented Appwrite auth, collection APIs, admin CRUD, Collect.js and Gateway.js checkout, dual payment modes, BIN policy, and maintenance controls in TypeScript with shared models. Quality gates — Prettier, ESLint, typecheck, and Husky — kept the admin and payment contracts aligned as the domain grew.

  4. 04Testing

    Flows were proven across login and recovery, business and user lifecycle, relationship policy, brand and BIN rejection, remaining-limit math, 3-D Secure challenge completion, scheduled-charge field construction, gateway approval parsing, and maintenance takeover of public checkout.

  5. 05Launch

    The product ships as a live Next.js application with environment-driven Appwrite and gateway configuration, operator documentation in the console itself, and a confirmation record for every approved sale or scheduled payment.

Challenges

Hard problems, clear outcomes

A checkout that is trustworthy without becoming a PCI liability

Problem

Payers expect a branded card form. The organization cannot afford for primary account numbers to pass through its servers, logs, or database.

Approach

We embedded Collect.js hosted fields, configured inline brand preview and validation callbacks, and treated the payment token as the only card artifact the application is allowed to hold.

Outcome

The product presents a complete checkout while remaining a token-and-policy system. Secret keys stay on the server; the browser only ever loads a public tokenization key for the selected relationship.

Policy that is finer than a user and finer than a merchant

Problem

The same collector may work across several gateway accounts, each with different tokens, brand rules, BIN lists, limits, and 3-D Secure requirements.

Approach

We introduced a saved payment method document as the join between user and business, and we built the admin form so every subscribed business exposes that full control set.

Outcome

Operators configure each relationship independently. Checkout loads only the selected relationship, so policy cannot leak from one merchant destination to another.

Two ceilings that have to agree in real time

Problem

A charge that is legal for a collector may still exceed the business daily cap, and the reverse is also true. Showing either number alone would mislead the payer and the operator.

Approach

Checkout computes remaining capacity as the minimum of unused user-daily and unused business-daily value, blocks over-limit input, and increments both ledgers only after the gateway returns approval.

Outcome

The amount field and the remaining-limit label always describe what can actually clear, and approved volume is reflected on the next visit.

Issuer-level card control without a brittle rules engine

Problem

Brand allowlists are not enough. Organizations need to accept or refuse specific six-digit BINs, and they need that list maintained in one place.

Approach

We built a master BIN directory with automatic brand detection from BIN prefixes, then let each relationship attach those BINs as an allowlist or a blocklist per card type.

Outcome

Operators maintain one catalog and apply it surgically. Checkout compares the tokenized BIN before a charge is attempted, so disallowed cards fail in product, not at the gateway.

3-D Secure as a product path, not a popup accident

Problem

Authenticated checkout introduces a second UI, extra billing fields, and cryptographic results that must travel with the sale or the scheduled payment.

Approach

We made 3-D Secure a relationship flag that forces billing capture, mounted Gateway.js in a dedicated modal, and forked payment APIs so authentication fields are first-class on both immediate and scheduled posts.

Outcome

Operators enable 3-D Secure per relationship. Payers complete a coherent challenge. The server submits a complete authenticated payload.

One public host that must freeze on command

Problem

Payment links are live URLs. When the organization needs a pause, those URLs cannot keep accepting cards while engineering prepares a deploy.

Approach

A single admin-controls document drives a notification banner and a maintenance takeover of public checkout, readable on every load.

Outcome

A master manager can publish a message and take accept-payment offline as an operational act.

Proof

What this work proves

PayLink centralizes a previously fragmented collection workflow — one link per user, many merchant destinations, and a master console for policy, capacity, and downtime. Organizations can issue, share, and govern payment links without handing collectors raw gateway secrets. Payers complete tokenized, optionally authenticated, immediate or scheduled charges against a visible remaining limit. Operators see daily and lifetime volume on both the collector relationship and the business, and they can stop a relationship, a merchant, or the entire public surface without leaving the product.

Fintech product designPCI-aware checkout architecturePayment gateway integrationMulti-entity SaaS modelingOperations console designAuthentication and session architectureRisk and card-policy controlsAPI-driven web platformsResponsive product interfacesTypeScript full-stack engineering

What's next

Intelligent fraud and BIN guidance

Extend the existing brand and BIN policy with scoring and recommended allow/deny actions so operators can tighten risk on the same relationship model they already manage.

Operations analytics and settlement reporting

Build a reporting chapter on top of the daily and lifetime ledgers already stored on users and businesses — trends, collector performance, and merchant throughput in one view.

Richer scheduled-payment plans

Grow the current single-charge schedule into multi-payment plans, reminders, and operator-visible upcoming charges without changing the public-link model.

Have something in mind?

Tell us about your product and we'll help you ship something worth putting on this page.

→Start a project

Next project

RasaCard

Virtual Visa cards, issued instantly, funded your way.

View case study