MerchantE

Connect your merchant's MerchantE account to process credit card transactions through Preczn.

MerchantE is a direct processor: each merchant holds their own MerchantE account, and the two MerchantE credentials are stored on that merchant's connection in Preczn. There is no platform-level MerchantE connection and no merchant boarding — a merchant must already have a MerchantE account before it can be connected.

Supported Capabilities

Capability	Status	Notes
Credit Card Transactions	Supported	Full lifecycle — sale, auth, capture, void, refund, and verify
Level II and Level III Data	Supported	Tax, freight, and line-item detail on qualifying cards
AVS and CVV Results	Supported	Returned on every card transaction
ACH (Bank Account) Transactions	Not supported	Bank-account payments cannot be routed to MerchantE
Apple Pay / Google Pay	Not supported	Wallet transactions cannot be routed to MerchantE
Merchant Onboarding	Not supported	Merchants sign up with MerchantE directly, then link their account

Supported Transaction Types

Type	Description
Sale	Authorize and capture in a single request
Auth	Authorize only (hold funds without capturing)
Capture	Capture a previous authorization, in full or in part
Void	Cancel an authorization
Refund	Return funds from a completed transaction, in full or in part
Verify	Validate a card without charging it (see Verify)

Adding Merchant Credentials

MerchantE requires two values, both found in the merchant's MerchantE account. Both are required — a connection saved without either one is rejected.

Credential	API field	CSV column	Description
Profile ID	`key`	`profile_id`	Identifies the merchant's profile
Profile Key	`secret`	`profile_key`	Authenticates requests for that profile

There is no merchant ID to supply — the Profile ID serves that purpose, and the connection form does not ask for one.

📘
Credential Verification
Preczn verifies MerchantE credentials with MerchantE when you save them, so a mistyped Profile ID or Profile Key is caught at configuration time rather than on the first transaction.

Enter them on the merchant's MerchantE connection in the Dashboard, or send them to the connection update endpoint — see Linking Existing Credentials. They can also be supplied when importing merchants via CSV, using the column headers in the table above.

Processing Transactions

Route transactions to MerchantE the same way as any other connection — through a plan or a direct connection reference on the transaction. The sections below cover the behavior specific to MerchantE.

Synchronous Outcomes

MerchantE returns the outcome of every transaction on the API response itself. There are no status callbacks to configure and no asynchronous settlement step, so a MerchantE transaction is A (Approved), D (Declined), or E (Error) the moment the request completes — it never sits in P (Pending) waiting for a later update.

Verify and Card Checks

A Verify on a MerchantE connection is performed as a zero-dollar authorization, so it validates the card without moving money and without a capture to reverse. An Auth for zero is treated the same way.

Captures and Refunds

Captures and refunds may be for the full amount or a partial amount. A full capture uses the amount MerchantE actually approved rather than the amount originally requested, which matters when an authorization was approved for less than it asked for.

AVS and CVV Results

MerchantE returns address and card-code verification results on every card transaction, and Preczn normalizes them to its standard values:

Preczn result	Meaning
`M`	Match
`N`	No match
`P`	Partial match — some address elements matched but not all (AVS only)
`U`	Unavailable or not checked

Send the billing street address and postal code to get a meaningful AVS result, and the CVV to get a card-code result.

Stored Credentials and Card on File

When a transaction uses a stored payment token, Preczn flags it to MerchantE as a card-on-file transaction. Single-use tokens and raw card data are not flagged. MerchantE's card-on-file flag does not distinguish customer-initiated from merchant-initiated or recurring use, so all stored-credential transactions carry the same indicator. See Card On File Flags.

Level II and Level III Data

MerchantE accepts enhanced data, which can qualify commercial and purchasing-card transactions for better interchange:

Preczn field	Sent to MerchantE as
`order`	Invoice number
`dutyTax`	Duty amount
`freightTax`	Shipping amount
`items`	Line-item detail (see below)

⚠️
Two limits worth designing around
The invoice number is truncated to 10 characters. An order value longer than that reaches MerchantE cut short, so keep order numbers destined for MerchantE within 10 characters if you reconcile on them.
Line items are sent for Visa, Mastercard, and American Express only. Each brand has its own line-item format, and MerchantE offers none for Discover — so items on a Discover transaction is stored by Preczn but not transmitted. Tax and freight amounts are still sent for every brand.

See Level II Data and Level III Data for how to populate these fields.

Statement Descriptors and Merchant Detail

MerchantE accepts merchant identification alongside each transaction — name, phone, category code, city, state, postal code, and website. Preczn sources these from the merchant's record, and sends the dynamic statement descriptor as the merchant name when one is supplied on the transaction.

Data Sent to MerchantE

Preczn forwards the cardholder first and last name, billing street address and postal code, phone number, and email address with each card transaction.

MerchantE's API has no equivalent for the following, so these are accepted by Preczn and used elsewhere but never reach MerchantE:

Metadata
The full shipping address — the shipping amount is sent as Level II freight data, but shipping address fields are not

Transaction Status Mapping

MerchantE response	Preczn status	What it means
Approval code	`A` Approved	The transaction succeeded; `processorCode` carries MerchantE's auth code
Decline code	`D` Declined	MerchantE or the issuer rejected the transaction
Anything else	`E` Error	The request itself failed — a connectivity problem, or a request MerchantE could not process

On a decline, MerchantE's own response text is surfaced as processorMessage, so the reason the issuer gave is available on the transaction without a separate lookup.

Testing in the Sandbox

Add the merchant's MerchantE connection in Test Mode using their MerchantE sandbox Profile ID and Profile Key.
Send transactions using the standard Preczn test cards — Preczn substitutes MerchantE's sandbox card numbers automatically, so no processor-specific test data is needed for approvals.

To exercise declines and error handling against MerchantE specifically, ask MerchantE for the sandbox values that trigger them.

Test and Live connections are configured separately, and Preczn routes each transaction to the matching MerchantE environment based on the mode it runs in.

FAQ

Where do I find the Profile ID and Profile Key?

Both come from the merchant's MerchantE account. A merchant who cannot locate them should ask their MerchantE representative — Preczn cannot retrieve them.

Do I need a platform-level MerchantE connection?

No. MerchantE is a direct processor, so both credentials live on the individual merchant's connection. Each merchant uses their own MerchantE profile, and there is no shared platform credential to configure.

Why isn't there a merchant ID field?

MerchantE identifies the account by its Profile ID, so no separate merchant ID is needed and the connection form doesn't ask for one. If you're migrating configuration from another processor, the Profile ID is the value that plays that role.

Can I take ACH or bank-account payments through MerchantE?

No. MerchantE is card-only in Preczn, and a bank-account payment is never routed to it. Route ACH volume to a connection that supports it — see ACH (Direct Debit).

Can I send Apple Pay or Google Pay transactions?

No. Wallet transactions cannot be routed to MerchantE; a wallet transaction sent to a MerchantE connection is rejected as unsupported. Route wallet volume to a connection that supports it — see Apple Pay on the Web and Google Pay for Web.

Why didn't my line items reach MerchantE on a Discover transaction?

MerchantE supports line-item detail for Visa, Mastercard, and American Express, each in its own format, and offers no equivalent for Discover. Line items on a Discover transaction are stored on the Preczn transaction but not transmitted. Duty and shipping amounts are still sent on every brand, so Level II data is unaffected.

Why is my order number shortened on the MerchantE side?

MerchantE's invoice number field accepts 10 characters, and Preczn truncates longer values rather than having the transaction rejected. The full order value stays intact on the Preczn transaction — only the copy sent to MerchantE is shortened. If you reconcile between systems using the invoice number, keep order numbers within 10 characters.

Does a Verify charge the cardholder?

No. A Verify on MerchantE is run as a zero-dollar authorization, so no funds are captured and there is nothing to void afterward. It confirms the card is valid and returns AVS and CVV results, which makes it useful for validating a card before storing it.

Can a MerchantE transaction come back Pending?

No. MerchantE returns its decision on the API response, so every transaction is Approved, Declined, or Error by the time the request completes. There are no callbacks to wait for and no webhook to configure in MerchantE.

Can I board new merchants to MerchantE through Preczn?

No. Preczn connects merchants who already hold a MerchantE account; it does not submit applications to MerchantE. Once the merchant has their Profile ID and Profile Key, add them to the merchant's connection and transactions can be routed immediately.