Changelog
Back to All

8/26/2026 Release

6 days ago by Clay Hefner

This release adds Frame as a new processor connection — card sale, refund, auth, capture, and void plus ACH sale and refund — alongside configuring location webhook events in the dashboard, transaction metadata now reaching CardPointe's reporting as userfields, and a corrected MCC 1711 description on the boarding form.

Jump to: New Features · Improvements · Bug Fixes

New Features

Frame transactions

Frame is now a supported processor: card and ACH transactions route through Frame end to end, from connection setup through asynchronous status reconciliation. A Frame connection is configured once at the platform level with your Frame secret and publishable keys, and each merchant carries only its Frame sub-merchant account id — there is no per-merchant secret to manage. Full setup steps, the supported transaction matrix, and status mapping are in the Frame connection guide.

  • Sandbox and production from one set of credentials. The environment is determined by the key you paste: an sk_sandbox_* key routes to Frame sandbox, an sk_production_* key to production. There is no separate URL or environment setting to keep in sync.
  • Credentials are verified before they're saved. Adding or updating a Frame connection validates the secret key live against Frame, so a mistyped or revoked key is caught at configuration time instead of at the first transaction.
  • Card payments: sale, refund, auth, capture, and void. Captures support partial amounts and multiple sequential captures against a single authorization. A void before any capture releases the full authorization; after a partial capture, it releases the uncaptured remainder. Refunds support partial and multiple partial refunds up to the original amount, on both directly-captured sales and auth-then-capture transactions.
  • ACH sale and refund. Bank-account payments route with account number, routing number, and account type. ACH authorization, capture, and void are not offered on Frame — ACH has no authorization-hold concept — and are rejected rather than silently attempted. ACH returns arrive asynchronously and surface as a declined transaction.
  • Payment method verification is not available on Frame. Frame provides no $0-authorization mechanism, so a verify transaction against a Frame connection returns an unsupported-operation error. Card data validates at charge time through Frame's decline codes.
  • Declines carry retry guidance. Frame's decline codes are mapped to Preczn's soft (retryable — for example insufficient funds) and hard (terminal — for example stolen or expired card) categories, so your retry logic sees the same distinction it does on every other connection. Frame does not expose raw AVS or CVV result codes; address and CVV mismatches surface only through the decline code.
  • Asynchronous statuses reconcile automatically. Both event families Frame uses — transfer events for sales and refunds, charge-intent events for authorizations, captures, and voids — are mapped to Preczn transaction statuses, so a transaction that settles, fails, or is returned after the initial response updates on its own without polling. Inbound webhooks are verified by HMAC signature before anything is processed, so an unsigned or tampered delivery never enters the pipeline.
  • Webhook endpoints register themselves. When Frame credentials are added or rotated, Preczn registers the webhook endpoint at Frame, subscribes both event families, and captures the signing secret Frame issues once at creation. Secret rotation persists the new secret before the old one is retired, so there is no window where deliveries fail verification.
  • Manual signing-secret entry. A Frame endpoint registered by hand in Frame's dashboard issues a signing secret that now has a home: the platform connection carries a webhook signing secret field, entered write-only and masked on read, separate from the API secret key. Where automatic registration also runs, it takes precedence over a typed value.
  • Sandbox test values. Preczn's standard test card and test bank-account values map to Frame's sandbox equivalents, so the same test payloads you use on other connections work against Frame. Frame's sandbox rejects real card numbers outright.

Location event subscriptions in the dashboard

location.created, location.updated, and location.deleted can now be subscribed to from the dashboard webhook form, instead of only through a direct API call.

  • A new Locations group on the webhook form. Creating or editing a webhook offers the three location events as checkboxes alongside the event families already there, and a subscription created through the API that already includes location events opens with those boxes checked — editing and saving it no longer risks dropping them.
  • The Events card is grouped by what the events describe. Events are now organized into two labelled sections — Merchant (lifecycle, locations, and forms) and Transactions & loans — each showing how many of its events are selected. The merchant lifecycle group is now labelled "Lifecycle" so the hierarchy doesn't read "Merchant > Merchant"; the event names themselves are unchanged.

Improvements

Transaction API

  • Transaction metadata now reaches CardPointe reporting. metadata sent on a transaction to a CardPointe-connected merchant is forwarded to CardPointe as userfields on sale, authorization, and verify requests — previously it was accepted by Preczn and never passed on. Each metadata key becomes a CardPointe user field of the same name, and metadata is sent exactly as supplied, never truncated. One caveat worth knowing: CardPointe caps the encoded user fields at 4,000 bytes and silently discards all of them past that point while still approving the transaction, which is only reachable near Preczn's metadata maximums; the full metadata always remains intact on the transaction record in Preczn regardless. Metadata is not sent on capture requests — the values attached at authorization already belong to the CardPointe transaction record.

Bug Fixes

Boarding form

  • MCC 1711 now names plumbing. The description for MCC 1711 read "Air Conditioning" on the application, so plumbing contractors couldn't find their category and were unsure which code to pick. It now reads "Heating, Plumbing, and Air Conditioning Contractors". Display text only — the submitted MCC value is unchanged.