Changelog
Back to All

10/15/2026 Release

15 days ago by ReadMe API

This release adds locations to boarding forms, with an Adyen for Platforms store for every location, and two new boarding connections, Jack Henry and Synchrony, alongside Apple Pay and Google Pay on Frame and a transaction detail drawer in the dashboard.

Jump to: New Features · Improvements · Bug Fixes

New Features

Locations in boarding forms

Boarding forms can now collect a merchant's physical locations, each with its own settlement account. You turn the feature on per template. A template that displays no location fields renders and saves exactly as before.

  • Turn on locations in Field Customization. The boarding-form template editor has a new Business Location section with Location Name, MCC Code, Phone, Set As Primary Location, and a grouped Location Address. Each field has its own display toggle and subtext. The form shows locations when at least one of these fields is displayed. Templates created before this release show every location field turned off.
  • Form templates API. Form templates carry the new section as customFormFields.businessLocation. When you create a template with POST /v1/formTemplates and leave out the businessLocation display settings, every location field defaults to off. Other sections keep their existing defaults.
  • One tab per location on the Business Location step. When locations are on, the business address card is retitled Legal Business Address, and a tab bar below it holds one Location Details card per location. Each tab shows how many required fields remain. The merchant can add and remove locations. Removing a saved location asks for confirmation.
  • Fewer keystrokes per location. A new location's name, MCC, and phone are prefilled from the business details the first time the merchant reaches the step. Copy business address copies the legal business address into a location once that address is complete. The location's street address field offers Google Places suggestions for US and Canadian addresses, and picking one fills the street, suite, city, state, postal code, and country.
  • Primary location is optional. Set as primary location appears only when the template displays it and the merchant has more than one location.
  • Assign settlement accounts on the Banking step. When a connection on the form collects per-location data, each bank account card gains Settles payments for, with one checkbox per location. Nothing is preselected. Ticking a location that settles to another account moves it, and the card says which account it currently settles to. When a connection requires a settlement account for every location, the merchant can't continue until each location is assigned.
  • Deleting a bank account names the affected locations. If locations settle to an account the merchant deletes, the confirmation dialog lists them, and they become unassigned.
  • Primary account subtext now renders. The Banking step shows the subtext you configure for Set As Primary Account (banking.fields.primaryAccount.displayAttributes.subText) beneath the checkbox. Use it to tell merchants what the primary account funds.
  • Review shows locations and missing items. The Review step adds a Locations tab that summarizes each location and its settlement account, and the Banking tab lists every uploaded document by name. Missing required items appear in a list, and each entry opens the step and tab where the merchant can fix it.
  • Saves recover from partial failures. If saving one location or one settlement assignment fails, the form names it, keeps everything that saved, and Retry re-sends only the calls that failed.
  • Greensky boards from the primary bank account. Greensky boarding now uses the bank account the merchant marked as primary, as Payrix, Stripe, Rainforest, and Jaris already do. Preczn uses the first account only when no account is marked primary. Merchants with one bank account see no change.
  • Know the limits. The dashboard merchant detail doesn't yet display or edit per-location connection data. You can't add a location through a boarding form after a merchant is approved.

Adyen for Platforms: a store for every location

Adyen for Platforms boarding now provisions Adyen resources for each of a merchant's locations, so each location can settle to its own bank account. Merchants with no locations board exactly as before.

  • Per-location provisioning. For a merchant with locations, boarding creates a store, a balance account, and the store's payment methods for each location. Each store's Adyen reference is the Preczn location ID. When a location's settlement account has no transfer instrument yet, Preczn creates one. Locations that share a bank account share its transfer instrument.
  • Optional split configuration. Adyen for Platforms platform connections have a new optional Split configuration profile id setting (up to 100 characters) in the add and edit connection drawers. When it's set, Preczn applies the profile to each new location store with that location's balance account. Changing or clearing it affects stores boarded afterward. Stores that are already boarded keep their profile.
  • Every location needs a settlement account. The Adyen for Platforms requirements template now includes a locations block. A merchant with no locations is still complete. Each location that exists must have a bankingId, and a location without one is reported as locations[i].bankingId in the merchant's missing requirements. Boarding forms that serve Adyen for Platforms show Settles payments for on the Banking step and require an assignment for every location.
  • Location status in the Merchant API. After boarding starts, each location's connectionData includes a Preczn-managed AdyenForPlatforms entry with its store, balance account, and boardingStatus (pending, provisioned, or error). Location responses and location webhooks carry it. You can't create or edit this entry. Sending one on POST or PATCH /v1/merchants/{merchantId}/locations returns a 400, and a PATCH that leaves it out keeps it.
  • The connection goes Active when every location is ready. The connection becomes Active only after every location is provisioned and Adyen allows the account holder to receive payments. If Adyen rejects one location, the connection moves to Error with a message that names the location and Adyen's error code. Retrying boarding re-provisions only the locations that need it.
  • New Payment Methods tab in the dashboard. On an Adyen for Platforms connection in merchant detail, payment-method boarding status moves to its own Payment Methods tab. The tab groups status by location, shows a count of boarding failures, and offers Retry boarding when a location is pending or failed.
  • Missing settlement accounts appear under Banking. The dashboard's merchant connection drawer now lists a location's missing settlement account under Banking instead of Business.
  • Know the limits. This release covers boarding only. Payments don't yet route to a location's store or balance account. Editing a location after its store exists doesn't update the store at Adyen. Deleting a location or bank account doesn't close Adyen resources.

Adyen for Platforms: signed terms and PCI before boarding

Adyen for Platforms boarding now requires signed terms and a signed PCI questionnaire, and a merchant who changes business structure partway through onboarding can finish without manual help.

  • Signatures are required before boarding. An Adyen for Platforms connection that isn't yet Active, Disabled, or Closed no longer boards until the merchant has accepted the terms of service and signed the PCI self-assessment questionnaire. Without both, the connection stops at Requirements before Preczn contacts Adyen. This applies to every path that starts boarding: boarding-form submission, the onboard API, and dashboard onboard or re-board.
  • The PCI step always appears for Adyen for Platforms. Boarding forms that serve Adyen for Platforms now always include and enforce the PCI step, even when the template turns it off. GET /v1/forms/{formId} reports displayPciSaq: true for these forms. Your stored template setting doesn't change. Merchants sign the PCI questionnaire in a boarding form. The API has no separate signing path.
  • Business-structure changes restart Adyen onboarding. When a merchant switches between sole proprietorship and an organization business type after Adyen for Platforms onboarding has started, Preczn sets up a new Adyen legal entity of the correct type and asks the merchant to sign the terms and PCI questionnaire again before boarding continues. Changes between organization types don't trigger this. Connections that are Active, Disabled, or Closed are never reset.
  • Permanent PCI errors show a support message. When Adyen rejects the PCI questionnaire for a reason a retry can't fix, the boarding form shows a contact-support message, with your support email and phone when configured, instead of a Retry button. If the merchant's terms need signing again, the PCI step offers Go to Terms & Conditions.

Jack Henry merchant boarding

You can now add Jack Henry as a connection and board merchants to Jack Henry for ACH (check and bank debit) processing. Jack Henry is a boarding-only connection: payments don't route through Preczn. Preczn submits the application, uploads the merchant's documents, checks Jack Henry for status changes once a day, and sends you a merchant webhook on each change. For the full guide, see the Jack Henry connection page.

  • Connect Jack Henry in the dashboard. In Connections → Add Connection, select Jack Henry and enter the values Jack Henry issued to your platform: Client ID, Client Secret, Customer Service Provider ID, Request Email, Velocity Recipient Email, FI Recipient Email, and the four File Upload credentials. All ten are required. Preczn checks both credential sets with Jack Henry before it saves the connection.
  • ACH limits for each location. Every Jack Henry application needs at least one location with a settlement account (bankingId) and five ACH limits: debitSingleTransAmount, debitSingleDayCount, debitSingleDayAmount, debitPeriodCount, and debitPeriodAmount. Send them in a JackHenry entry of the location's new connectionData array on POST /v1/merchants/{merchantId}/locations and PATCH /v1/merchants/{merchantId}/locations/{locationId}. Each value must be a whole number of 0 or more. Other values return a 400 that names the field. Location data in merchant webhooks now includes connectionData.
  • connectionData replaces the stored array on update. Preczn matches entries by id. An entry you leave out of a PATCH is deleted, so send the whole array back when you change one entry. Entries that Preczn manages itself, such as Adyen for Platforms entries, are kept.
  • New boarding-form steps for Jack Henry. A form that includes Jack Henry adds a Jack Henry ACH Setup step, with one panel per location and a link to copy the limits from the previous location. It also adds a Jack Henry Contacts step, where the merchant picks or adds the primary contact who receives Jack Henry's application-status emails. That contact must have a title. Jack Henry forms don't include a Terms & Conditions step, because Jack Henry has no Preczn-hosted terms.
  • Partnerships need two owners. On a form that includes Jack Henry, a business whose type is Partnership can't continue past the Owners step with fewer than two owners. Jack Henry rejects a partnership application with only one owner.
  • The primary representative signs. The owner marked primaryRepresentative becomes Jack Henry's Primary Officer, who receives Jack Henry's email to review and e-sign the application. Exactly one owner must be marked. Otherwise the connection moves to Error before anything is sent to Jack Henry.
  • Documents go to Jack Henry automatically. Upload a voided check and bank statements to the merchant, each 4.3 MB or less. Preczn sends them to Jack Henry right after it creates the application. If an upload fails, fix the document and onboard again. Preczn uploads only the missing documents and doesn't resubmit the application.
  • Status tracking. The connection moves to Sent when Jack Henry creates the application, and Preczn stores the application ID. Preczn then checks Jack Henry once a day while the connection is Sent, Underwriting, or RFI. Jack Henry's review and signature stages map to Underwriting. On Hold Pending Additional Info maps to RFI, with Jack Henry's request in actionDescription. Installation Complete maps to Active, and Preczn stores the Jack Henry merchant ID. Declined maps to Rejected, and Cancelled maps to Cancelled.
  • Know the limits. Preczn removes single quotes from every value it sends, including email addresses, and shortens long values to Jack Henry's limits. Preczn doesn't respond to a Jack Henry RFI for you. Resolve it with Jack Henry directly. Jack Henry boards US businesses only.

Synchrony merchant enrollment

You can now add Synchrony as a connection and enroll merchants with Synchrony through its Digital Enrollment API. Synchrony is a boarding-only connection. Preczn submits the merchant's enrollment, checks Synchrony for status changes once a day, and sends you a merchant webhook on each change. For the full guide, see the Synchrony connection page.

  • Connect Synchrony in the dashboard. In Connections → Add Connection, select Synchrony and enter the Client ID and Client Secret that Synchrony issued to your platform. Click Verify connection to check the pair with Synchrony before you save.
  • Each merchant needs a Synchrony campaign code. Synchrony issues a campaign code for each merchant's program and tier. Set it in connectionspecificRequirements.synchronyCampaignCode with PATCH /v1/merchants/{merchantId}/connections/{connectionId}, in the merchant's connection drawer, or in the Create New Merchant drawer. The code can be up to 255 characters after trimming. Send an empty string to clear it. Sending null or leaving the field out keeps the stored code. The boarding form doesn't collect the campaign code, so a merchant who boards through a form stays in Requirements until you set it.
  • Merchants accept Synchrony's terms on the boarding form. A form that includes Synchrony now shows a Synchrony Terms & Conditions step. The merchant scrolls to the end, enters the signer's first and last name, and checks the acceptance box. If you board through the API, send connectionspecificRequirements.tosDate and tosIp on the merchant's Synchrony connection. The connection stays in Requirements until both are present.
  • A default requirement template covers what Synchrony needs. Adding the connection creates a Default Synchrony Requirements template. It requires business identity, addresses (including the mailing address), and annual volumes; each owner's identity, contact details, home address, and SSN; the primary bank account; the campaign code; and terms acceptance. The second mailing address line is the only optional field.
  • Synchrony receives one principal. Preczn sends the owner marked primaryRepresentative as the enrollment's principal. A merchant with several owners and none marked fails with an Error that names the field.
  • Status tracking. After submission, the connection moves to Sent. Preczn then checks Synchrony once a day. Synchrony's in-review stages map to Underwriting, and actionDescription shows the current Synchrony stage. On Hold also sets actionRequired. Approved maps to Active, and Preczn stores Synchrony's merchant ID. Declined maps to Rejected, and Withdrawn or Cancelled maps to Cancelled.
  • Preczn never submits a merchant twice. Synchrony doesn't detect duplicate enrollments. After Synchrony accepts an enrollment, onboarding the merchant again doesn't resubmit it. The dashboard locks the campaign code once the enrollment is submitted. If a submission times out or Synchrony returns a server error, the connection moves to Error with actionRequired, because the enrollment might exist. Confirm with Synchrony before you onboard again.
  • Know the limits. Preczn shortens values to Synchrony's limits: city 25 characters, street address 76 characters (both lines joined), owner first and last name 20 characters each, and legal name 120 characters. Annual sales volume above $99,999,999 is sent as $99,999,999.

Frame: card verify, Apple Pay, and Google Pay

Frame connections now support card verification and Apple Pay and Google Pay payments. Card captures, refunds, and timeouts are also more predictable. Your Frame connection settings, credentials, and webhook setup stay the same.

  • Card verify works on Frame. A verify routed to a Frame connection now runs as a zero-amount card authorization instead of returning an unsupported-operation error. Preczn always sends an amount of zero, so no funds are held or moved. You still can't verify a bank account through Frame.
  • Apple Pay and Google Pay on Frame. You can now send an Apple Pay or Google Pay sale or auth to a Frame connection with the same single-use wallet token flow that you use on other connections. Capture, void, and refund a wallet auth the same way as a card auth. Wallet verify isn't supported on Frame.
  • Wallet payments are checked before they reach Frame. A wallet payment needs a complete billing address. An Apple Pay payment must also be unexpired and match the exact amount the customer approved. A payment that fails a check returns HTTP 400 before anything is sent to Frame. The processorCode names the reason: WALLET_BILLING_ADDRESS_REQUIRED, WALLET_TOKEN_EXPIRED, WALLET_AMOUNT_MISMATCH, WALLET_CRYPTOGRAM_REQUIRED, WALLET_INVALID_AUTH_METHOD, or WALLET_UNSUPPORTED_TRANSACTION_TYPE. If your checkout changes the amount after Apple Pay approval, for example to add a tip, ask the customer to approve the new amount first.
  • Wallet payments in test mode. In test mode, Preczn sends an Apple Pay or Google Pay payment to Frame's sandbox with a Frame test card of the same brand. Wallet testing needs no Frame-specific card data.
  • One processorTransactionId per payment. A sale or auth now shares its processorTransactionId with every capture, void, and refund that follows it, so one ID finds the whole payment in Frame.
  • Safe retries after a timeout. If Frame doesn't respond to a sale, auth, or verify in time, retry with the same Idempotency-Key header as the original request. Frame returns the original result instead of charging again. Preczn never retries a timed-out capture, refund, or void automatically. Check the transaction in Frame before you send it again.
  • Concurrent captures and refunds are serialized. If you send a capture or refund while another capture or refund on the same Frame payment is still running, you get HTTP 409 with Another operation on this transaction is in progress; retry shortly. Nothing is sent to Frame. Retry when the first request finishes.
  • More Frame declines carry retry guidance. More Frame decline codes now map to Preczn's soft (retryable) or hard (terminal) decline categories. For example, card_velocity_exceeded, incorrect_zip, and issuer_not_available are soft, and restricted_card, pickup_card, and security_violation are hard.

Transaction detail drawer

In the dashboard, a transaction now opens in a drawer over the Transaction Log instead of on a separate page. When you close the drawer, the log is exactly as you left it.

  • Your place in the log is kept. Closing the drawer keeps your filters, page, and scroll position, and the list doesn't reload.
  • Links still work. Each open transaction has its own /transaction-log/<id> address. A shared link or an old bookmark opens the log with that transaction's drawer already open. Use Copy link in the drawer header to share it.
  • Grouped Overview with Fee, Tax, and Source. The Overview tab groups the transaction's fields and adds Fee, Tax, and a labeled Source (Imported or Native). The transaction's description, order details, statement descriptor, and shipping address now appear in the API data tab's raw record instead of the Overview.
  • Everything else in tabs. The drawer has Overview, API data, Processor data, and Webhook deliveries tabs, plus a transaction lifecycle timeline. You can still view each webhook delivery attempt and resend a webhook from the Webhook deliveries tab. For an imported transaction, the API data tab is unavailable and explains why.

Improvements

Merchant API

  • The Merchant API rejects a PO box as a physical address. Creating or updating a merchant now returns 400 when address.address is a PO box, and creating or updating a location returns 400 when address.address1 is a PO box. This matches the boarding form. mailingAddress still accepts a PO box, and existing merchants and locations that already store one are unchanged.

Dashboard

  • Merchant Vault matches the rest of the dashboard. The Merchant Vault now uses the same design as the Users, Transaction Log, and other updated pages. Each merchant shows its full MID and EID with a copy button, and the Columns menu has Reset to default. Hover over an onboarding connection's status to see its boarding details. Your saved columns, filters, sorting, and bookmarked filter links still work.
  • Merchant Vault actions moved. Use Add Merchant at the top of the page to add a merchant. When you select merchants, a bar with Move Merchants, Update Cohort / Labels, and Delete Merchants replaces the Bulk Actions menu. You can no longer edit labels inside the table cell. Use Update Cohort / Labels in the row's actions menu instead. The Refresh button is removed.

Boarding form

  • Steps are grouped by connection. On a form with two or more connections, each connection now has one step in the sidebar, with that connection's steps beneath it, such as Terms & Conditions, Contacts, Account Login, PCI Compliance, or ACH Setup. The grouping appears on desktop, tablet, and mobile. Forms with one connection and RFI forms keep their current steps.
  • No empty Terms & Conditions step for Jaris. A form that includes Jaris no longer shows a Terms & Conditions step that only said terms weren't available.
  • NAICS Code is hidden unless your template turns it on. Boarding forms show the NAICS Code field only when the form template enables it. New templates start with the NAICS Classification Code toggle off. If you board merchants to Jack Henry, which requires a NAICS code, turn the toggle on in your template.

Bug Fixes

Boarding form

  • The Review step shows the NAICS code. When a boarding form displays the NAICS code field, the Review step now lists the merchant's selected NAICS Code directly after MCC Code, or Not provided if the merchant left it empty.
  • Required business fields show clear errors. Annual Sale Volume shows a required-field message when left blank, the missing-fields notice names every incomplete Business Information field, and Days to Ship is enforced when a requirement template marks it required.
  • Save & Continue checks only the current step. On the Business Identity, Business Location, and Business Operations steps, the "Missing required fields" message lists and blocks on only the fields shown on that step.
  • Billing Contact fields are checked on the Business Location step. The form now highlights missing or invalid Billing Contact fields on the step where they appear.
  • Optional phone fields stay optional after you clear them. A merchant who types in an optional phone field, such as the Billing Contact phone, and then clears it can continue without a "required" error.
  • Back no longer warns about unsaved changes that don't exist. On the Business Identity, Business Location, and Business Operations steps, a merchant whose form was prefilled with whole-dollar amounts can select Back without seeing the "You have unsaved changes" prompt when they haven't edited anything.
  • Owner Zip Code stays required after you pick a country. Selecting an owner's country no longer drops the required check on Zip Code, and the owner tab's remaining-fields count includes it.
  • Deleting an owner keeps the open owner in view. When a merchant deletes an owner tab to the left of the one they're editing, the form stays on the same owner instead of switching to a different person.
  • Uploaded owner and bank documents stay visible. A document uploaded for a new owner or bank account now shows as uploaded when the merchant returns to the step, without a page refresh. Choosing Discard removes any documents uploaded on that step since its last save.
  • The Banking step recovers when a save or load fails. If saving or loading banking details fails, the loading screen now clears and the error appears, so the merchant can correct the details and try again without reloading the page and losing their edits.
  • Days to Ship is fully visible. The Operations & Processing section on the Business Operations step no longer scrolls internally or cuts off the Days to Ship field.

Dashboard

  • Connection drawer lists missing documents. The connection drawer on merchant detail and the Merchant Vault now lists required documents, such as a bank statement or voided check, and counts them in the completion totals, so its numbers match Connection Onboarding. The drawer also shows its onboarding alert in full and fixes hover states that made the vault row menu, onboarding rows, and Edit Plan connection cards hard to read.
  • Filter panels no longer show a stray horizontal scrollbar. The category list in the filter panel on the Merchant Vault, Transaction Log, Users, and other filterable pages now scrolls only vertically.
  • Dashboard loading placeholders stay inside their cards. While the dashboard home page loads, each card's loading placeholder now appears inside that card instead of spreading across the page.

Ramp

  • Ramp rejections with nested errors name the field to fix. When Ramp rejects a boarding application with nested field errors, the connection's Action Required message and the merchant-update webhook now include Ramp's reason and the name of each rejected field, instead of generic text. Preczn also checks owner dates of birth before submitting and flags any year of 1900 or earlier, which Ramp doesn't accept.