Book a scoping call
Home / Blog / Identity

Identity: locking the front door without losing the customer

Verification is the cheapest security control you will ever buy and the easiest one to implement badly. The difference is entirely in the details.

Live example Real customers in, fakes out
  • 00:00Signup attempt from a number we have never seen.
  • 00:01Number checked: prepaid mobile, carrier known, not a virtual range.
  • 00:03Code sent. Rate limits applied by number, account and address.
  • 00:19Verified. Account created.
  • 00:22Second attempt, same number, third account today. Blocked.

What it actually does

A code, push or cryptographic challenge is issued to a channel the customer controls, then checked with strict rate limits and short expiry.

Checkout, subscriptions, deposits, progress claims, terminals and reconciliation wired to the systems that record them. In practice, Identity is the version of that we deploy when a business needs the result rather than a project. Adapted from the payment provider's public sample integration identity, then hardened for idempotency, retries and reconciliation against your accounting system.

Why businesses ask for this

Taking the payment is the easy part. Making the payment agree with the invoice, the job and the ledger is where businesses lose hours and money.

The people who get the most out of it: online sellers, service businesses taking deposits, and anyone billing on a schedule.

  • Deposits and progress claims collected without a phone call
  • Recurring maintenance plans that bill themselves
  • Payments reconciled to invoices automatically, with mismatches flagged

How we build it, step by step

The sequence below is the one we follow on every identity assurance build. It is deliberately boring, because the interesting version is the one that breaks in month three.

  1. Pick the primary channel by delivery rate in your actual customer base
  2. Set the fallback order and the retry backoff
  3. Rate limit by number, by account and by IP
  4. Log every attempt for the audit trail without logging the code itself
The part most people skip: proving it. Before anything goes live we run it in staging against real historical cases from your business and hand you the transcripts. You sign off on what it did, not on what it was supposed to do.

What we change before it goes live

A reference implementation is a starting line, not a product. Every one we deploy gets the same treatment:

  • Your numbers, your sender identity and your wording, so nothing reads as generic
  • Secrets moved out of the code and into managed configuration
  • Retries, rate limits and idempotency, so a hiccup never sends twice
  • Structured logging and alerting, so a failure is noticed by us and not by a customer
  • Consent, opt-out and record-keeping built in rather than bolted on
  • Source control, a staging environment and a rollback that takes a minute

Compliance and risk

Card data never touches your systems, every operation is idempotent so a retry cannot double charge, and the two ledgers are reconciled on a schedule with an alert on drift.

We set the technical controls up correctly and document what we did. We are not lawyers, and anything unusual about your industry gets flagged in writing so you can take advice on it before launch rather than after.

The technical foundation

A payment provider's hosted components, webhooks into a service we run, and a reconciliation job against your accounting system.

  • typescript — a supported runtime.

References worth reading before you buy this from anyone:

What it costs

Three ways to buy this, and the honest recommendation is usually the middle one:

  • Starter build, from $2,500 — we build it, hand it over and warrant it for 30 days. Suits a business with someone technical in-house.
  • Managed, from $390/mo — we build it and then own it: monitoring, changes, compliance upkeep and a monthly report. Suits everyone else.
  • Platform, from $2,400/mo — when this is one of several systems and you want them designed as one layer instead of five.

Platform usage is billed at cost on top and itemised on the invoice. There is no margin on it and no minimum spend.

Common questions

How long does Identity take to build?

For a standard configuration, about a week from kick-off to a staging number you can test on, then a few days of live monitoring before we call it done. Anything involving a port of an existing phone number adds one to two weeks of carrier time that nobody controls.

What does it cost to run each month?

Two lines: our managed plan from from $390/mo, and platform usage billed at cost. Usage for this kind of system usually lands between $30 and $300 a month depending on volume. You see both itemised, and the platform account stays in your name.

Do we own it, or are we locked in?

You own it. The account, the numbers, the phone history and the source code are yours, and the foundation is open source. If you take it in-house, we hand over the repository and the runbook and that is the end of the conversation.

What if it breaks at 6pm on a Friday?

It is monitored. Failures raise an alert, the system degrades to something safe rather than silent, and hello@betr.agency is the inbox that answers. That is what the managed plan buys.

Can it work with the systems we already use?

Usually yes. A payment provider's hosted components, webhooks into a service we run, and a reconciliation job against your accounting system. Where a system has no API, we look at whether an export, a shared inbox or a scheduled sync gets you 90 percent of the value for 10 percent of the cost.

Where to next

The product page for this build lists the specification, the timeline and what is included: Identity. If you want to talk it through against your actual process, a scoping call is 30 minutes and costs nothing.

[ // / RELATED ]

Builds that pair with this one

Same pattern or same product line, and often bought together.

Want this running in your business?

Tell us what happens today, by hand. We will tell you what it costs to stop doing it.