DEV Community: Daniel Wilson Kemp

PAX A920 in 2026: What End-of-Life Means for Merchants

Daniel Wilson Kemp — Mon, 03 Aug 2026 10:24:07 +0000

The PAX A920 is still installed in a lot of merchant environments, but the buying decision changed in 2026.

PAX's current North American product page labels the original model A920 (EOL). That is an important procurement signal. It is not, by itself, proof that every installed A920 must be unplugged today.

Short answer: do not order the original A920 for a new deployment without written confirmation from the organization supporting the complete payment configuration. An existing A920 can remain usable only while its hardware, security support, payment application, processor configuration, and merchant deployment are all still supported.

This is the distinction merchants and developers need to make.

End-of-life is a lifecycle signal, not a transaction response

A payment terminal does not become unusable merely because a product page changes. The fielded system has several independent support boundaries:

Boundary	The question to ask
Hardware	Can the device, battery, printer, charger, and radios still be supported?
Firmware and security	Is the installed firmware still accepted under the provider's security and compliance program?
Payment application	Is the exact app build approved and assigned to this model?
Processing configuration	Does the processor or acquirer still support this terminal, application, host, and merchant setup?
Merchant operations	Do sales, receipts, reversals, refunds, settlement, and support escalation still work as designed?

PAX itself still publishes the original A920 product page and an A920 quick setup guide. The product page's title currently carries the EOL label. Treat that label as a reason to verify the whole stack, not as permission to guess in either direction.

A920, A920 Pro, or A920 Max?

PAX's own A920 family comparison describes three different positions:

A920: the compact original model for basic mobile or countertop acceptance. PAX currently marks this model EOL.
A920 Pro: the performance step up, with a larger display and newer hardware. PAX lists Wi-Fi, LTE, Bluetooth, an integrated printer, camera capability, and PAXSTORE access on its A920 Pro PCI 5 page.
A920 Max: the premium member of the line for environments that need more display, battery, and processing headroom.

PAX also announced a newer A920Pro PCI 7 in April 2026. PAX describes Android 14, PCI PTS 7, a 6.56-inch main display, a secondary customer-facing display, 4G LTE, Wi-Fi, Bluetooth, eSIM support, an integrated scanner, and a 6000mAh battery.

Those specifications matter, but they do not choose a payment terminal for you. The correct model is the one supported by the payment application, processing configuration, merchant category, connectivity plan, and operating workflow being deployed.

When an installed A920 can reasonably stay in service

Keep an existing device only when the responsible provider can confirm all of the following:

The serial number remains assigned to the correct merchant and location.
The device firmware and security posture remain supported.
The required payment and business applications still receive managed updates.
The processor configuration is still supported for that merchant account.
Chip, contactless, swipe fallback, receipt, reversal, refund, and settlement workflows have been safely validated.
Wi-Fi or cellular connectivity is stable in the real operating environment.
There is a documented support and replacement path.

A device that turns on is not necessarily a supported payment deployment. Conversely, an EOL procurement label does not automatically erase a working, supported installed base.

PAXSTORE approval is necessary evidence, not the entire deployment

PAX describes PAXSTORE as its device and application management ecosystem. That distribution layer is one of the reasons Android payment terminals can carry business applications alongside the configured payment stack.

But three statements are different:

the application build is approved for distribution;
the application is assigned to a particular device;
the merchant's complete production workflow is ready.

Do not collapse them into one claim.

For example, Lifted Payments currently offers two PAX PayDroid applications:

Lifted Pay is the standalone merchant-operated application for qualified card-present deployments.
Lifted POS Connect is the payment companion that receives a sale from LiftedPOS, presents the supported tender flow on the terminal, and returns the result to the register.

PAXSTORE approved Lifted Pay version 0.0.5 and Lifted POS Connect version 0.2.9 on July 27, 2026. That is evidence about the named application builds and their distribution status. Merchant rollout still requires supported hardware, processing configuration, boarding, and validation.

A practical first-boot and handoff checklist

The official PAX quick guide covers the physical basics: inventory the terminal, power supply, and paper roll; prepare the battery; and hold the power key for roughly three to five seconds.

For a production handoff, extend that checklist:

Record the model, serial number, location, owner, and intended payment application.
Charge the device fully and inspect the battery, printer, charging contacts, and paper path.
Join the approved Wi-Fi network or validate the managed cellular plan.
Confirm the correct PAXSTORE assignment and let all managed updates finish.
Verify the merchant identity and processing configuration before taking a payment.
Run a controlled card-present test through the real workflow.
Confirm the result appears in the expected reporting and receipt surfaces.
Safely test the supported reversal or refund path.
Document who owns terminal, app, processing, and connectivity support.

That last item matters. A merchant should never have to discover during an outage that four vendors each believe someone else owns the problem.

Replace the device when support becomes ambiguous

Replacement is the safer choice when any of these are true:

the provider will not confirm continuing model or firmware support;
managed updates no longer arrive;
battery, printer, or connectivity failures are recurring;
the payment application is not approved or supported on the installed build;
the merchant cannot safely test reversals, refunds, or reporting;
security or compliance policy requires a newer device generation;
downtime and support cost now exceed the value of keeping the device.

For new purchases, get the complete supported configuration in writing before ordering hardware. The terminal model alone is not the solution.

The merchant decision is bigger than the terminal

A PAX device is one layer of a payment system. The merchant account, processing configuration, terminal application, POS or gateway workflow, reporting, refunds, connectivity, and support ownership all have to agree.

The full PAX A920 setup and application guide maintains the current model comparison, setup steps, PAXSTORE explanation, troubleshooting path, and merchant-deployment checklist in one place.

If the goal is a new processing relationship rather than hardware-only research, start with the merchant application so the business, risk profile, hardware, and software path can be evaluated together.

Source note: product names and specifications above are based on the linked PAX Technology North America pages reviewed August 3, 2026. Availability, certification, firmware, and provider support can change. Confirm the exact configuration before purchasing or fielding a device.

A Processor-Neutral JSON Schema for Auditing Payment Processing Statements

Daniel Wilson Kemp — Sun, 02 Aug 2026 16:32:52 +0000

A Processor-Neutral JSON Schema for Auditing Payment Processing Statements

Merchant processing statements are built for billing, not comparison. Two statements can describe the same monthly card volume with different labels, subtotals, credits, and pricing structures. That makes the basic question—“what did accepting cards actually cost?”—harder to answer than it should be.

We published version 1.1.3 of the Lifted Payments Payment Statement Audit Model to make that calculation explicit, reproducible, and independently verifiable. The release includes:

a spreadsheet-ready CSV template;
a JSON Schema Draft 2020-12 contract;
a Decimal-safe companion validator;
exact methodology and field definitions;
two valid and fourteen deliberately invalid synthetic test vectors;
a deterministic validation report and SHA-256 inventory; and
a fail-closed publication gate.

The maintained guide and downloads live at liftedpayments.com/payment-processing-statement-audit. The exact release is archived as doi:10.5281/zenodo.21764642 and published from GitHub v1.1.3.

The canonical release archive has SHA-256 digest b1d398ada2bb456de0fffc5278b68a48554ffd5d80232d654416102ad87d5897. That digest is the simplest way to confirm that a downloaded copy is the release described here.

Start with one declared calculation basis

Version 1.1.3 uses gross settled purchase volume and net processing fees:

gross_processing_fees = exact sum(fee_groups.amount)
total_processing_fees = gross_processing_fees - statement_credits
effective_rate = round_half_up(total_processing_fees / card_volume, 6)
average_ticket = round_half_up(card_volume / transaction_count, 2)

For the synthetic example:

$2,864.75 / $125,000.00 = 0.022918 = 2.2918%

The JSON value is 0.022918, not 2.2918. Multiply by 100 only for display.

The denominator is gross settled purchase volume with its matching settled purchase count. It excludes declines, authorization-only events, voids, refunds, chargebacks, reserves, and funding adjustments. The numerator is net processing fees after gross fee groups reconcile exactly and processing-fee credits are reported separately.

That basis matters. Dividing fees by deposits, net sales after refunds, or authorization volume can produce a plausible-looking percentage that is not comparable.

The record makes its assumptions machine-readable

A shortened v1.1.3 record looks like this:

{
  "schema_version": "1.1.0",
  "calculation_basis": "gross_settled_purchase_volume_and_net_processing_fees",
  "statement_period": {
    "start": "2026-06-01",
    "end": "2026-06-30"
  },
  "currency": "USD",
  "card_volume": 125000.00,
  "transaction_count": 1860,
  "gross_processing_fees": 2864.75,
  "statement_credits": 0.00,
  "total_processing_fees": 2864.75,
  "effective_rate": 0.022918,
  "average_ticket": 67.20,
  "pricing_model": "interchange_plus",
  "fee_groups": []
}

The published example includes the complete fee-group array. Categories are unique, and their exact cent sum must equal gross_processing_fees.

pricing_model uses a bounded set:

interchange_plus
flat_rate
tiered
subscription
dual_pricing
unknown

unknown is intentional. A parser should preserve uncertainty rather than infer a pricing model from one line item.

Normalize labels into stable fee groups

Statement labels vary, but the economic roles are more stable:

interchange — issuer/interchange charges;
assessments — network assessment, access, and brand charges;
processor_markup — percentage, basis-point, per-item, or service markup;
authorization — authorization, capture, AVS, gateway, and batch items;
monthly — account, statement, minimum, and recurring platform charges;
pci — compliance-program or non-validation fees;
equipment — terminal rental, device service, or connectivity charges;
chargebacks — dispute-administration fees, not transaction principal; and
other — ambiguous processing-related charges, with a note.

The model does not assume every fee is avoidable. It makes the statement explainable. If a processing charge cannot be classified confidently, put it in other and document why; do not omit it to make a rate look better.

JSON Schema is necessary, but not sufficient

The schema handles types, required fields, enums, bounds, and unknown-field rejection. Cross-field accounting rules need a semantic validator.

Install the pinned dependencies and run both a record and the public corpus:

python -m pip install -r requirements-validation.txt
python tools/validate_audit.py examples/payment-statement-audit-example.json
python tools/validate_audit.py --corpus
python tools/publication_gate.py --mode package
python tools/publication_gate.py --mode candidate
python tools/publication_gate.py --mode published

The validator loads JSON numbers directly as Decimal. It also rejects:

duplicate JSON keys and non-finite numbers;
invalid or reversed dates and periods longer than 62 days;
fractional cents and over-precise rates;
fee totals, credits, effective rates, or average tickets that do not reconcile;
ambiguous zero-volume and zero-count combinations;
duplicate fee categories and unknown fields;
excessive input size or nesting depth; and
likely payment, banking, identity, email, or credential data in notes.

Validation errors return a rule code, JSON Pointer path, and fixed message without echoing the submitted value.

The exact merge worktree passed 81 automated tests. A fresh copy unpacked from the published ZIP passed the same 81-test suite, with one Git-history-only immutability regression skipped as designed. Package mode passed 14/14 internal checks, the clean tagged candidate passed 15/15 readiness checks, and published mode passed 16/16 only after GitHub, Zenodo, DOI resolution, Hugging Face, and Software Heritage matched the reviewed commit and archive bytes. The deterministic report accepts two valid synthetic records and rejects fourteen adversarial records for their expected rules.

Those results demonstrate the declared contract, package integrity, rejection behavior, repository provenance, and public artifact identity. They do not prove that an arbitrary source statement was transcribed correctly, and they are not a security guarantee.

Version 1.1.3 keeps the 1.1.0 record contract unchanged while separating portable package validity from candidate readiness and published attestation. Before candidate Python can run, the gate checks the complete manifest, canonical paths, bounded sizes, UTF-8 and LF portability, SHA-256 coverage, credential signatures, release identity, clean committed tree, authoritative origin, complete remote tag inventory, exact tag alignment, and monotonic version. The public attestor is bounded and non-executing; it rejects unsafe redirects, oversized responses, archive traversal, case-fold aliases, symlinks, undeclared members, digest drift, and mismatched public identities.

The gate is not an accounting opinion, legal review, interchange-pricing guarantee, or malware sandbox. Automated screening cannot prove arbitrary prose contains no confidential information, so human review remains mandatory before public release.

The release was also exercised against 1,000 deterministic hostile JSON-native and direct-value records. Every case returned structured validation results rather than crashing the validator or leaking submitted values into error messages.

Keep the public-data boundary strict

This model needs statement-level aggregates. It has no field for card numbers, cardholder identity, bank details, credentials, or merchant-owner information.

Never put these into a public repository, prompt, issue, or dataset mirror:

full or partial card numbers, expiration dates, or security codes;
track, PIN, or PIN-block data;
bank account or routing numbers;
passwords, API keys, tokens, or authentication values;
tax IDs, government identifiers, or owner Social Security numbers;
merchant-identifying notes; or
an unredacted real statement.

Automated screening reduces accidental disclosure. It cannot prove arbitrary prose is safe, so a human still has to review every public record.

What the model cannot tell you

An effective rate is an all-in normalization of the included statement costs. It can support consistent month-to-month or provider-to-provider comparisons when records use the same basis.

It cannot:

prove the source statement was transcribed correctly;
decide whether a fee is contractually permitted;
determine whether interchange was qualified correctly;
predict a future statement;
replace legal, tax, or accounting advice; or
guarantee savings.

Card mix, ticket size, acceptance channel, rewards mix, disputes, seasonality, and statement timing can move the result without a pricing change. Present the rate with the underlying dollars, volume, count, fee groups, and period.

Cite or reuse the exact release

The model is licensed under CC BY 4.0. The requested citation is:

Lifted Payments. (2026). Lifted Payments Payment Statement Audit Model (Version 1.1.3). Zenodo. https://doi.org/10.5281/zenodo.21764642

Public distribution surfaces:

GitHub is the versioned source, Zenodo is the persistent DOI archive, and Software Heritage preserves the exact source history. The Hugging Face catalog copy exposes the same v1.1.3 ZIP; an anonymous download matched the canonical archive digest above.

For a quick manual check, the free effective-rate calculator performs the core math in the browser without transmitting the values entered.

If you want a payments team to review a private statement and design processing technology around how the business actually operates, start the Lifted Payments merchant application.

Level 2/3 interchange data: how B2B card payments qualify for lower rates

Daniel Wilson Kemp — Mon, 27 Jul 2026 14:06:50 +0000

If you build or run software that takes B2B card payments, there's a lever most merchants never pull: Level 2 and Level 3 interchange data. Send the card networks more structured detail about a commercial-card transaction, and that transaction can settle at a materially lower interchange rate. Here's how it actually works.

Interchange, briefly

Every card transaction carries an interchange fee set by the card networks (Visa, Mastercard, etc.) and paid to the card-issuing bank. It's the largest, effectively non-negotiable component of what a merchant pays to accept a card. Interchange isn't one number — it's hundreds of rate categories, and which one a transaction lands in depends on the card type, how it's accepted, and the data submitted with it.

Commercial cards — corporate, purchasing, business, and government cards — have their own interchange categories, and those categories reward richer data.

Level 1 vs Level 2 vs Level 3

Level 1 — the default. Just the basics: card number, amount, date. Every transaction has this.
Level 2 — adds a few fields: sales tax amount, a customer/PO reference number, and tax status. Valid Level 2 data can qualify a commercial-card transaction for a lower interchange tier.
Level 3 — adds full line-item detail: per-item description, product code, quantity, unit of measure, unit price, line-item tax, freight/duty, and more. This is the richest tier and the one purchasing and government cards are built around.

The catch: the data has to be valid. Networks validate it. A placeholder tax amount or a bogus product code won't qualify — and in 2026 the bar got higher (Visa folded its old standalone Level 2 incentive into the Commercial Enhanced Data Program, which requires accurate enhanced data plus a small participation fee).

A concrete example

Say a distributor charges a business customer $5,000 on a corporate Visa card:

Level 1 (basics only):        standard commercial rate
Level 2 (+ tax, PO number):   reduced commercial tier
Level 3 (+ full line items):  lowest commercial tier

The exact basis-point difference depends on the card and network rules, so I won't quote a fixed number — anyone who guarantees you a specific rate is guessing. But on large-ticket B2B volume, the gap between Level 1 and Level 3 on commercial cards is meaningful and compounds.

How to actually send it

Three things have to line up:

Your gateway/processor has to support it. Many don't append Level 2/3 well, or make you pass every field by hand. Some gateways append it automatically when the card is commercial and the data is present.
You need the data. Level 2 is easy — you almost always have tax and an invoice/PO number. Level 3 means passing your line items through at charge time (your cart or invoice already has them).
The card has to be a commercial card. Consumer cards don't qualify for these tiers, so there's nothing to optimize there.

If you're wiring this up yourself, the practical pattern is: detect the commercial BIN, then attach the enhanced-data object (tax, PO, line items) to the authorization/capture request. If your gateway supports auto-append, you send the line items once and it handles qualification.

Why it matters for B2B software

If your product invoices other businesses — SaaS, wholesale, marketplaces, field service — a non-trivial share of your card volume is commercial cards. Getting Level 2/3 right is one of the few ways to lower effective processing cost without changing your prices or your pricing model.

For a deeper, vendor-neutral walkthrough — the specific fields for each level and how qualification is decided — I wrote it up here: Level 2/3 processing: how commercial-card interchange optimization works. There's also a companion piece on B2B credit card processing for the business-side view.

Disclosure: I'm the founder of Lifted Payments, where we append Level 2/3 automatically on commercial cards, so I have skin in this game. But the mechanics above are card-network rules, not vendor magic — any processor that supports enhanced data can do this. If yours doesn't, that's worth a conversation with them.

Lifted Sign: a self-hostable e-signature server that runs on nothing but SQLite

Daniel Wilson Kemp — Thu, 23 Jul 2026 08:37:23 +0000

Most e-signature tools send signatures. Very few let you own the whole thing — the documents, the signers, and the audit trail — on your own hardware. We built Lifted Sign to be the one you can self-host, and to be genuinely boring to run: it boots on nothing but SQLite.

Repo: https://github.com/LiftedHoldings/lifted-sign (AGPL-3.0)

The pitch, honestly

Upload a PDF, place fields, add signers, send single-use signing links. Each completed document is cryptographically sealed and ships with a Certificate of Completion — the audit trail of signer identities, timestamps, IP addresses, and consent records that ESIGN and UETA actually call for.

The difference is where all of that lives: your infrastructure, not a vendor's cloud. Data residency and air-gapped deploys are the default, not an enterprise tier.

SQLite by default

This is the part I'm happiest with. Lifted Sign boots with zero external services — one secret, and you're signing:

docker run --rm -e SIGN_SECRET=$(openssl rand -base64 48) -p 8080:8080 ghcr.io/liftedholdings/lifted-sign

Open http://localhost:8080 and you have a working signing server. SIGN_SECRET is the only required setting; every login session, signer-access cookie, and one-time code is keyed off it, so the server fails closed and loud if it's missing, too short, or a placeholder. Point it at Postgres with a single env var when you outgrow a file.

Real PAdES certification, not a flattened image

A lot of "e-signature" ends up being a signature image burned into a PDF. Lifted Sign gives completed PDFs a PKCS#7 / PAdES digital signature that any PDF reader can verify and that breaks visibly if the file is altered. No signing certificate installed yet? It falls back to a tamper-evident AES-integrity seal, so a completed document is never left unsealed.

How signing works

Prepare. Drop in a PDF, place signature/date/text/checkbox fields by anchor, add signers.
Send. Each signer gets a single-use link. They review, hit the ESIGN/UETA consent gate, and sign in the browser — no account required.
Seal. Once everyone signs, the PDF is sealed with a PAdES certification signature and a Certificate of Completion. Download both, or pull them via the API.

Developer-first

There's a clean REST API under /api/mysign/* for creating envelopes, adding signers, placing fields, sending, reminding, voiding, and downloading sealed PDFs and certificates. The in-app /developers page documents the endpoints and serves an OpenAPI spec.

Ready-to-use, dependency-free clients are vendored in the repo — a Python client (3.8+, standard library only) and a Node client (18+, built-in fetch/FormData). Both are MIT-licensed even though the server is AGPL, so integrating against Lifted Sign never touches your application's licensing. Point either client's base_url at your own install and drive it.

Build from source

git clone https://github.com/LiftedHoldings/lifted-sign.git
cd lifted-sign
cp .env.example .env
python -c "import secrets; print('SIGN_SECRET=' + secrets.token_urlsafe(48))"  # put this in .env
pip install -e .
python -m sign        # or: docker compose up

Why AGPL, and why free

Self-hosting is GA and free forever under the AGPL — no seat limits, no volume policing, no "contact us." The license is the only agreement. Passwordless email magic-link sign-in works out of the box; SMTP, Postgres, Google/phone sign-in, and PAdES certificates are optional add-ons you switch on by env var as you grow.

If you'd rather not run it, there's a managed instance in free open beta at https://sign.liftedholdings.com — same software, TLS and backups handled — but the self-hosted path stays free regardless.

Repo + docs: https://github.com/LiftedHoldings/lifted-sign
Architecture write-up (the ESIGN/UETA model, the three-runtime design, the persistence and security layers) lives in docs/ARCHITECTURE.md
Built by Lifted Holdings; see also Lifted Payments for interchange-plus merchant services with 3-D Secure card processing.

It's a debut open-source project, so contributors are what turn it into a community — there are good first issue labels waiting. Bug reports, docs, tests, and code all welcome.

Lifted ShipKit: open-source multi-carrier shipping labels with forced 3-D Secure

Daniel Wilson Kemp — Thu, 23 Jul 2026 08:36:26 +0000

Shipping labels are one of those features that look trivial until you actually build them. You need a carrier-rating API, a payment step, PCI scope for the card data, and — the part nobody warns you about — a fraud problem, because labels bought with stolen cards are a top chargeback category. Real goods, shipped fast, disputed weeks later.

We open-sourced Lifted ShipKit to collapse that whole stack into a few lines of code. It's MIT-licensed, self-hostable, and it ships with a drop-in checkout widget that forces 3-D Secure on every card charge.

Repo: https://github.com/LiftedHoldings/lifted-shipkit

What it actually is

ShipKit is a Kotlin/JVM backend plus a dependency-free browser widget. The backend wraps EasyPost for real multi-carrier shipping — address verification, live USPS/UPS/FedEx rate compare, SmartRates, label purchase, batch, scan forms, customs, and tracking webhooks — and adds a payment layer on top of it. The widget is a UMD global (window.ShipKit), so it mounts in plain HTML, React, Vue, Svelte, or anything else with a <script> tag and no build step.

The part I want to talk about is the payment layer, because that's the design decision that makes ShipKit different from "just call EasyPost yourself."

Why forced 3-D Secure is the whole point

Most teams that add shipping wire a rating API straight to a payment processor and then quietly own two things they didn't sign up for: the PCI scope for card data, and the chargeback liability when a fraudster buys a label with a stolen card.

ShipKit forces 3-D Secure on every card charge. The issuer authenticates the buyer before the label prints, which shifts fraud-and-chargeback liability off the merchant. Card data goes through hosted fields, so it stays out of your PCI scope. This isn't an enterprise upsell or a config flag you can forget to turn on — it's always on, by construction.

For a product whose fraud profile is "real goods, shipped immediately, disputed later," making authentication non-optional is the correct default.

60-second try

No account, no keys — the published Docker image comes up immediately (shipping and payment features return 503 until you supply an EasyPost key and 3DS credentials):

docker run --rm -e SHIPKIT_PORT=8080 -p 8080:8080 ghcr.io/liftedholdings/lifted-shipkit

Then open http://localhost:8080.

Drop it into your own checkout

The headline use case is keeping your app and your checkout and adding ShipKit for the rate-compare -> pay -> print-label step. Mount a node, point it at your backend, wire a callback:

<div id="ship"></div>
<script src="/js/shipkit.js"></script>
<script>
  ShipKit.init({
    mount: '#ship',
    endpoint: '/api',
    apiKey: 'pk_live_your_publishable_key',   // publishable pk_… key — safe in the browser
    onPurchase: ({ trackingCode, labelUrl }) => {
      // hand the finished label back to your order flow
    }
  });
</script>

Keys come in two scopes: the browser widget uses a publishable pk_… key (the backend confines it to the customer flow), while your server calls use a secret sk_… key that never appears in client code. Every surface restyles with --sk-* CSS variables — no !important, no build step.

Self-host it fully

git clone https://github.com/LiftedHoldings/lifted-shipkit.git
cd shipkit
cp .env.example .env                       # EASYPOST_API_KEY + your 3DS keys
./gradlew build                            # Kotlin 2.0.21, JVM 17
./gradlew shipkitKeygen -Plabel=my-store   # mint an API key
./gradlew run                              # API + widget on :8080

Every setting is read from the environment. Two optional, env-driven hooks let a platform operate a fleet of instances from a control plane — a bearer-guarded POST /api/config/markup to update the shipping markup remotely, and a fire-and-forget label.purchased webhook (carrier cost and buyer charge in integer cents) — both off by default when their tokens are unset.

Shipping as a profit center

One design choice worth calling out for anyone building a store: whoever owns the payments account owns the markup. ShipKit prices every label at the carrier rate plus your own percentage and fixed fee (percentage_markup + fixed_fee_cents), applied server-side and shown at checkout. Self-host it and that margin is 100% yours on every label.

Why open source it

Because the honest version of this tool is one you can read, fork, and run yourself. MIT license, dependency-free frontend, clean modular backend, no per-label SaaS fee when you self-host. If you'd rather not run infra, there's a managed tier and a 3-D Secure merchant-account tier — but the code, the widget, and self-hosting stay free.

Live demo: https://liftedholdings.com/shippingtool
Repo + docs: https://github.com/LiftedHoldings/lifted-shipkit
The payments side (interchange-plus merchant services with 3-D Secure, built by the same team): https://liftedpayments.com

If you build something with it, or you want ShipKit woven into your own framework, we'd genuinely like to hear about it. PRs and issues welcome.