A merchant should run its own operation.
insimbi is a proposed payments-control surface. It starts from one premise: the merchant decides how its operation runs, and can see the evidence behind every decision that touches its money.
Control, made legible
- 01Tickets that tie each line and later event to a source decision.
- 02Search, export and cutoff controls the merchant operates directly.
- 03Onboarding gates — business, customer, agent, then mandate — reviewed in order.
- 04Reporting that reconciles every row to its source ticket.
- 05Agent actions bounded by a mandate the merchant approves.
Concept stage, stated plainly
There is no live payment service, no customers, and no processing volume. The prototype runs locally on synthetic fixtures. Architecture decisions are proposed, not accepted; pricing and billing are undecided.
Brandnot cleared The name “insimbi” is a placeholder and has not been cleared.
Identity
The iris mark: an ink ring with a cusp segment. The wordmark is always lowercase. Palette values come from the design tokens; the cusp colour is marked provisional.
- cusp · light
#B5237F - cusp · dark
#E85DB6 - cusp deep
#8A1A61 - cusp wash
#F8E6F1 - ink
#111417 - ink secondary
#4A555B - page
#F4F6F7 - sunken
#E9EDEF - page · dark
#101315 - plated
#1F7A4C - working
#8A6516 - fired
#3D5C8C - void
#A32A22
Type: Schibsted Grotesk (sans) and Martian Mono (mono) when installed; system fallbacks otherwise.
Walk through the full prototype.
Eleven frames, light and dark, synthetic data throughout.