Sunday, August 30, 2026

Eric Kuvykin on Payment Economics: Interchange, Surcharging and Merchant Visibility

By Eric Kuvykin. Review and new notebook example: October 17, 2026. Original publication date retained.

Two payment proposals can reverse order when the number of transactions changes, even if total sales stay constant. Before comparing headline percentages, write down both sales volume and transaction count. A weighted basket is more informative than applying one average ticket to every kind of sale.

Use the same hypothetical basket

Assume 800 transactions at $10 and 200 at $100. That is 1,000 transactions and $28,000 in sales. For illustration only, Proposal A charges 2.5 percent plus $0.20 per transaction with no monthly fee. Proposal B charges 2.7 percent plus $0.05 per transaction and $30 per month. These are invented simplified proposals, not current market quotes or AMS offers.

Under those assumptions, A costs $700 plus $200, or $900. B costs $756 plus $50 plus $30, or $836. B is $64 lower despite its higher percentage. The result comes from the transaction-count component, not a claim that network interchange varies between these proposals.

Change one assumption at a time

Keep $28,000 of sales but reduce the count to 400 larger transactions. A becomes $700 plus $80, or $780. B becomes $756 plus $20 plus $30, or $806. A is now $26 lower. This is why a business expecting fewer, larger invoices should not copy the conclusion from a high-count checkout business.

For these simplified proposals, the monthly difference B minus A is 0.002 times sales, minus $0.15 times transaction count, plus $30. At $28,000 sales, the comparison crosses near 573.3 transactions; whole-number counts on either side produce different winners. This is a sensitivity calculation, not an annual percentage rate or a full contract-cost model.

Add the omitted contract fields

Next list software, equipment, gateway, refund, dispute, minimum, cross-border and termination charges where applicable. Confirm which fees are retained after a refund and whether any quoted component changes by channel or transaction category. Use each provider's actual terms and the same historical period before making a buying decision.

The SBA's startup-cost guidance distinguishes one-time and monthly expenses, a useful reminder to keep recurring and setup charges separate. The payment arithmetic here is an original hypothetical worksheet; it is not sourced market pricing.

A Florida retailer, New York service firm and New Jersey distributor may have different baskets. Start with actual records and the AMS regional reading paths, then use Eric's merchant decision worksheet to compare support and workflow alongside cost. This comparison does not determine whether a surcharge is permitted; check current applicable rules separately before changing checkout policy.

Fraud, Identity and Trust: Eric Kuvykin on Safer Payments for Small Business

By Eric Kuvykin. Review and new notebook example: October 17, 2026. Original publication date retained.

A fraud-review queue is difficult to judge when every blocked transaction is counted as a success. Some alerts identify a real problem, some interrupt legitimate business, and some remain unresolved. A useful review sheet keeps those outcomes separate instead of turning uncertainty into a favorable metric.

Give unresolved cases their own label

Imagine 100 fictional alerts. Reviewers later confirm 20 as fraudulent, 30 as legitimate and 50 as unresolved. Saying the system caught 100 fraud attempts is unsupported. Saying its false-positive rate is 30 percent is also misleading: 30 of 100 alerts is the observed legitimate share of this alert sample, not the false-positive rate across all legitimate transactions.

Even the 20 confirmed fraud cases do not reveal the system's recall, because this queue omits fraud that was never alerted. Keep the denominator written beside every percentage. Record when evidence was collected and allow an unresolved case to change status when later information arrives.

Describe evidence without collecting excess data

Use a case reference, alert reason, reviewer, review date, evidence source and final disposition. A customer's failure to answer a call should remain an unresolved contact outcome, not proof of fraud. An address mismatch is a signal to investigate under the provider's procedures, not a factual accusation about the customer.

For practice, include a legitimate repeat customer with a new device, an order with a mistyped address, a duplicate submission and a confirmed unauthorized transaction. These are invented training cases. Staff should explain what evidence distinguishes them and which actions require supervisor or provider approval. Do not put full card details or unnecessary personal documents into an informal spreadsheet.

Review queue quality alongside customer friction

Measure handling time, unanswered cases, repeated contacts and decisions changed after review. A shorter queue may mean better triage, but it may also mean cases were closed without evidence. Read a sample of closure notes before interpreting the count as improvement.

NIST's false-positive glossary illustrates the broader detection concept; this merchant worksheet is an operational recommendation, not a statistical validation or payment-network rule. Follow the actual processor's fraud and dispute procedures for live transactions.

For hypothetical teams in Florida, New York and New Jersey, use one set of outcome labels across locations so the results remain comparable. Continue through the AMS regional guides and Eric's payments and AI reading hub. A useful report makes uncertainty visible before anyone changes acceptance rules.

Eric Kuvykin on Instant Payments, Settlement Speed and Small-Business Cash Flow

By Eric Kuvykin. Review and new notebook example: October 17, 2026. Original publication date retained.

A payment can have several dates that are all correct for different purposes. The customer sees one local date, the payment service assigns a business date, and the accounting system imports the transaction later. A useful instant-payment readiness exercise is to trace those dates before treating a one-day mismatch as missing money.

Build a three-clock worksheet

For an authorized test or a fictional example, record the initiation timestamp with its time zone, service business date, bank availability timestamp and accounting import date. Preserve the unique payment reference on every row. Do not replace the original timestamp with a manually adjusted date just to make the totals match.

The Federal Reserve's FedNow operating-hours documentation describes a round-the-clock funds-transfer business day and a change to the next service business day at approximately 7:01 p.m. Eastern Time. That service boundary is a reason to retain both the event timestamp and business date. It does not establish the reporting behavior or availability of a particular bank's customer product.

Work through a cutoff example

Imagine a New York business initiates a fictional payment at 7:05 p.m. Eastern on a Monday. The local calendar still says Monday, while a service record may belong to the next funds-transfer business day. If an accountant filters one report by local calendar date and another by service business date, the transaction can fall into different daily totals.

The repair is a documented mapping rule, supported by the bank's actual export fields. It is not a second payment. Confirm the bank's availability record, transaction reference and reporting conventions, then record the reconciliation adjustment or timing explanation. A support timeout should be handled as an unresolved status until checked, not evidence that funds must be resent.

Put the date rule into cash planning

Keep the cash forecast based on verified usable funds. Compare earlier availability with fees and staff work; an earlier reporting date alone does not create additional cash. Bank instant payments, faster card payouts and financing are different products, so request the actual terms and support process for each.

For a Florida seasonal operator, a New York service business or a New Jersey supplier, one shared date dictionary can prevent inconsistent branch reporting. Continue with the AMS Florida, New York and New Jersey guides and Eric's financing cash-flow worksheet. Use the dates to explain the ledger before using them to make a spending commitment.

Embedded Finance for Main Street: Eric Kuvykin on Payments Inside Business Software

By Eric Kuvykin. Review and new notebook example: October 17, 2026. Original publication date retained.

When payments sit inside business software, familiar column names can hide different meanings. Sales, paid, settled and available are not interchangeable. Before connecting an application to accounting or using its dashboard for a financing discussion, make a one-page dictionary of the fields staff actually rely on.

Define the six fields

Start with order total, customer payment amount, refund amount, processing fee, payout contribution and payout reference. For each, record its source, whether it is gross or net, currency, relevant date and stable identifier. Name the person who owns the definition. Ask whether the application uses a negative number, a separate refund record or a status change to represent returned money.

Consider a fictional $600 order with a $20 partial refund and $18 in fees. With no other adjustments, its net payout contribution is $562. That is not necessarily a $562 bank deposit: the actual payout may group other sales, refunds and adjustments. A screenshot of gross sales cannot explain the bank total by itself.

Test the join, not just the totals

Export a small sample and match the order identifier to the payment reference, then to the payout reference. Look for one order with multiple payments and one payment with multiple refund entries. A spreadsheet join that assumes one row per order can duplicate the sales amount when a second refund row appears. The daily total may look plausible while individual orders are wrong.

Write the row grain at the top of each export: one row per order, transaction, balance movement or payout. Aggregate each file at the appropriate level before joining it to another. Retain unmatched records as an exception list instead of discarding them to make the report balance.

Ask the provider to demonstrate its meaning

Stripe's payout reporting guidance distinguishes automatic-payout reconciliation from manual payouts, where a direct transaction-to-payout relationship is not available in the same way. This is a product-specific example of why the report method matters; other providers may use different fields and settlement arrangements.

Use the same dictionary for a hypothetical Florida retailer, New York service business or New Jersey distributor, adding local operating resources through the AMS regional guides. For the financing implications, continue with Eric's cost and cash-flow guide. The practical result should be a record another staff member can reproduce, with assumptions visible and unexplained differences still open for review.

Eric Kuvykin on AI Adoption by Small Businesses: Useful Automation Beats Hype

By Eric Kuvykin. Review and new notebook example: October 17, 2026. Original publication date retained.

An AI workflow can change without a new subscription or a new application. A staff member edits the instructions, adds a spreadsheet column or changes the examples, and the same task starts producing different results. My practical recommendation is to keep a small change ledger beside the workflow.

A change ledger for a payment-support summary

Use fictional tickets to test a tool that summarizes deposit questions for a human reviewer. Save the instruction version, date, model or application version when available, test-set identifier, reviewer and reason for the change. The output must identify missing evidence rather than invent a deposit date or promise a refund.

For an illustrative comparison, version A correctly identifies the missing transaction reference in 8 of 10 tickets. Version B improves that to 10 of 10 but invents a funding date in two cases. Calling version B better because its first score improved would miss the more consequential error. Keep separate columns for useful extraction, unsupported statements and review time.

Keep the difficult examples

Retain cases with conflicting dates, incomplete references and two payments for one invoice. Use invented or properly de-identified data; do not put live credentials or full card details into the notebook. When a previously failing case passes, keep it in the test set so the next change cannot silently reintroduce the error.

Before release, the reviewer signs off on the comparison and records how to return to the prior instructions. Restrict the pilot to drafting internal summaries. Customer promises, refund approvals and payment changes remain separate authorized actions. A useful change log records the decision and evidence, not merely that somebody clicked Save.

Use the same method across locations

A Florida seasonal business may use weekend deposit questions; a New York service firm may use invoice follow-up; a New Jersey distributor may use incomplete remittance messages. These are hypothetical applications. The acceptance standard stays the same: source evidence, visible uncertainty and a named reviewer.

NIST's voluntary AI Risk Management Framework core organizes risk work around Govern, Map, Measure and Manage. This notebook applies that discipline at a small scale without claiming certification. Continue through Eric's four-topic hub and the AMS regional reading paths for Florida, New York and New Jersey for related operating resources.

Eric Kuvykin on Agentic Commerce and the Next Checkout Shift for Small Business

By Eric Kuvykin. Review and new notebook example: October 17, 2026. Original publication date retained.

An agent that finds an item has not necessarily received permission to buy it. Before testing AI-assisted checkout, separate recommendation, cart preparation and purchase authorization. A paper test ledger can expose a weak approval boundary without making a real transaction.

Write down what was approved

Use a fictional office-supply order with a maximum total of $150 including delivery and tax, one specified seller, and no subscription. Record the approved item, quantity, seller, delivery address category, total ceiling and expiry of the approval. These fields describe the test mandate, not permission for a live purchase.

Now create four test cards: the same order at $145; the same order at $158 after shipping; a cheaper substitute from another seller; and a $120 introductory price that starts a recurring plan. The first may remain inside the stated mandate. The other three require review because a material condition changed, even where the displayed initial price is lower.

Keep recommendation separate from completion

For each card, record expected behavior, observed behavior and evidence. The system should explain the changed condition and pause at the approval boundary. A chatbot message saying approved is weak evidence unless it is connected to the exact final cart and an authorized buyer's decision.

Repeat the cards after a prompt, catalog or checkout integration change. Include an expired approval and an unavailable item. Do not let the test silently convert an unavailable product into permission to choose another. Use a provider's documented test environment if evaluating a real integration; this notebook exercise makes no payments and stores no payment credentials.

Make the evidence useful to merchant support

Save the final item description, price components, cancellation terms, approval reference and order reference together. If a buyer later asks why a different item arrived, staff need the agreed cart, not just an AI conversation summary. Document who resolves a mismatch and when the workflow is stopped.

Stripe's agentic-commerce guide describes agent-assisted discovery and checkout with approval concepts. Product designs vary; that description does not establish that every agent has the same safeguards. Test the actual implementation and written permission model.

A hypothetical Florida seasonal retailer, New York office or New Jersey distributor can use the same ledger while selecting different purchasing constraints. Continue with AMS regional reading paths and Eric's fintech, payments, financing and AI hub. The practical goal is a purchase decision that can be explained before any money moves.