New features
- API: Idempotency is now supported for all payment operations (sale, refund, capture, void, and more). Pass a unique idempotency key per request to guarantee that retries never create duplicate charges, even across network failures or timeouts. See the Idempotency docs.
- API: Tax can now be configured on Payment Links and hosted Checkout pages, calculated inclusive or exclusive of the base amount and displayed as a clear subtotal/tax/total breakdown on the payer-facing page. See the Payment Links docs.
- Elements: AVS fraud protection now includes full street address verification in addition to ZIP code. See the Elements docs.
- Developer Portal: A public status page is now available showing real-time health and 30-day rolling uptime for all core services ISVs integrate with. See the status page.
Bug fixes
- Checkout: Fixed a validation gap where a payment session could be created with a
referenceIdexceeding 50 characters, only to fail with a cryptic error when the customer attempted to pay. ThereferenceIdis now validated at session creation, returning a clear error upfront.
New features
- MCP: Launched an open-source MCP server that lets AI coding assistants (Claude, Codex, Cursor) drive the full Flute payments platform through 47 typed tools covering transactions, ACH, customers, POS, terminals, settlements, subscriptions, and API token management. Production writes are disabled by default and credentials are stored in the OS keychain. Available via Homebrew or built from source (MIT license). See GitHub.
New features
- API v2: Settlement: The Settlement resource is now available in the v2 API. See the API reference.
Bug fixes
- iOS SDK: Fixed an issue where Tap to Pay and manual entry transactions could not be performed on sandbox merchant accounts in the iOS app, and the iPhone was not appearing in the Connected Devices list. Developers and QA teams can now fully test Tap to Pay flows in sandbox before going live.
- Elements: Fixed a bug where an already-spent Cloudflare Turnstile token was being reused across payment sessions, causing legitimate transactions to fail with a
bot_challenge_failederror. The token is now refreshed on every payment attempt and auto-retried on challenge failure.
Breaking changes
- API v2: Settlements (API reference): As part of v2 beta API refinements, the following fields were updated to align with naming conventions and guidelines:
statusrenamed tobatchStatuson list and response DTOsorderByrenamed tosortByon list requestsdateFromrenamed tofromDateanddateTorenamed totoDateon list requestsnetAmount,salesAmount,refundsAmountrenamed tototalNetAmount,totalSalesAmount,totalRefundsAmountbatchDateTimeremovedmessageandprocessorResponseCoderemoved from responses
Bug fixes
- Elements: Fixed a security gap where transactions were being approved despite a missing billing address when AVS was configured to Moderate or Strict. Both ZIP code and street address are now validated before authorizing a transaction.
New features
- API: Payment links can now be created and managed programmatically via the v2 API. Supports fixed amount, open amount, and standard checkout flows, with card and ACH/EFT, tipping, and merchant branding. See the Payment Links docs and API reference.
- API: The API now returns a clear
HTTP 401error when a sandbox API key is used against a production endpoint (or vice versa), preventing accidental real transactions during development. - Terminal SDK: ISV apps can now initiate a payment by calling a single method, handing off to the Flute Terminal app via deeplink for card read and processing, and receiving a typed result callback (approval, decline, or error) that automatically resumes the ISV app. No cloud round-trips or custom middleware required. Supported on certified Sunmi and Verifone device families. See the Terminal SDK docs.
- iOS SDK: Any compatible iPhone can now be used as a secure payment terminal, accepting contactless cards, digital wallets, and NFC-enabled devices without dedicated POS hardware. Ideal for integrations targeting mobile merchants, pop-ups, and field service providers. See the iOS SDK docs.
Bug fixes
- API: Fixed a delay where the POS terminal status remained "unavailable" for approximately one minute after a transaction completed. The terminal now updates to "available" as soon as the home screen is shown.
Bug fixes
- API: Fixed an issue where batch settlement data was lost during settlement processing due to a shared database context across parallel operations. Settlement records now reflect correctly via the API.
New features
- API v2: Added Transactions, POS Transactions, Terminals, and Webhooks to the v2 API. See the API reference: Transactions · POS Transactions · Terminals · Webhooks.
Bug fixes
- API: Fixed two AVS issues: transactions were being recorded with the wrong AVS response code, and the Strict AVS profile was incorrectly approving partial-match transactions that should have been declined.
Breaking changes
API v2: Webhooks (API reference): As part of v2 beta API refinements, the following fields were updated to align with naming conventions and guidelines:
webhookNamerenamed toendpointNamestatusrenamed toendpointStatuscreatedAtrenamed tocreatedOndeliveryAttemptStatusrenamed todeliveryLogStatussuccessrenamed toisDeliveredon ping/delivery responseseventTypechanged from an enum to a stringeventTypeIdremoved from event types responses- List and event-types responses moved from a
dataenvelope toitems - List endpoints are now paginated
API v2: Terminals (API reference): As part of v2 beta API refinements, the following fields were updated to align with naming conventions and guidelines:
orderByrenamed tosortByon list requestsasc(bool) renamed tosortOrder(string) on list requeststerminalPosStatusrenamed toterminalStatuson responseslastSeenTimestamprenamed tolastSeenOnterminalVersionrenamed toterminalAppVersionavailabilityStatusremoveddeliveryStatusremoveddeviceSoftwareDetailsobject removed
Bug fixes
- Terminal: Fixed an issue where POS transactions would become stuck in a
TransactionProcessingstate without activating the terminal, blocking all subsequent payment attempts on that terminal with a "Transaction is already in progress" error and requiring manual cancellation via API as a workaround.