Overview

Below is a summary of the connection key facts to support your integration.

Supported Features

The following features are supported for this connection:

Payment Methods

Payment Data

Transaction Import

Merchant Import

Merchant Onboarding

Adding Platform Credentials

For details on how to configure platform connections, first read the Connection Configuration guide.

This connection supports the following fields for connection configuration:

Adding Merchant Credentials

To establish an API connection with Payrix for a merchant who already has a relationship with them, you will need to provide the following credentials:

Merchant Onboarding Fields

Custom Field Use

Use connectionspecificRequirements.customField to send Payrix one value of your choosing with a merchant's application. Preczn passes the value unchanged to the custom field on the merchant's Payrix entity when it creates the entity. If you leave customField empty, Preczn omits custom from the request.

Payrix, not Preczn, decides what the value means. Agree on the values with your Payrix contact before you board merchants. For example, a platform moving merchants from another processor can send Conversion for moved merchants and New for new ones, so Payrix underwriting can review each group differently.

Boarding forms don't collect customField. Set it through the API before you submit the connection:

PATCH /v1/merchants/{merchantId}/connections/{connectionId}

{
  "connectionspecificRequirements": {
    "customField": "Conversion"
  }
}

The request updates only the fields you send. Values you already set, such as tosDate, tosIp, and tosVersion, stay in place. Preczn rejects a value longer than 50 characters.

The value appears in merchant API responses and merchant webhooks under the Payrix connection's connectionspecificRequirements.

Bank Account Disbursement History

Use hasDisbursementHistory on a merchant's bank account to tell Payrix whether the account already receives payouts from a payment processor. Payrix underwriting can use this to review an established account differently from a new one.

Payrix, not Preczn, decides what counts as disbursement history and how it affects underwriting. Confirm the criteria with your Payrix contact before you set the value.

If hasDisbursementHistory isn't set, Preczn omits description from the request.

Preczn sends one bank account to Payrix: the merchant's primary account, or the first account if none is marked primary. The flag on any other bank account isn't sent.

You can set hasDisbursementHistory in any of these ways:

• Merchant API. Include the field when you create a bank account, or update an existing one:

  HTTP

  PATCH /v1/merchants/{merchantId}/bankaccounts/{bankId}

  JSON

  {
    "hasDisbursementHistory": true
  }

• Merchant import. Give each bank account hasDisbursementHistory as TRUE or FALSE. Leave it empty to leave the value unset.

• Boarding form. Display the Has Disbursement History checkbox in the banking section of your form template, and the merchant checks it.

📘

Boarding forms always set a value

When a merchant saves a new bank account in a boarding form, Preczn stores false unless the merchant checks Has Disbursement History, so Payrix receives No. This happens even when your form template hides the checkbox. A bank account that already has a value keeps it when the merchant saves the form.

The value appears in merchant API responses and merchant webhooks on each bank account in banking.

Transaction Integration

Channel Field Use

In addition to standard transaction API request properties, Payrix offers an optional field, channel, which allows a string up to 1000 characters in length.

This field is only available on initial transactions, i,e. Sale or Authtransactions. Subsequent transactions against the initial transaction are not editable and will retain the same value of the initial transaction.

The channel field is surfaced in the Payrix Portal and can be used at your platform's discretion to associate additional information to a given Sale or Auth transaction.

Merchant RFI Remediation

At present, Payrix's underwriting team creates Request For Information (RFI) on a case by case basis via email. Typically, Payrix's underwriting asks are included in an email as a bulleted list, with the Merchant's name and Payrix MID in the subject line.

You may create a forwarding rule from your organization's domain to forward these emails to[email protected]. Preczn will then parse the email, and attach the action to the appropriate merchant in Preczn provided a matching Payrix MID and standard RFI email format is followed.

In addition to displaying the RFI on your merchant's profile in the Preczn dashboard, we also will return the list via api or webhook as the actionDescription object for you to consume and present in your application.

❗️

Review and Approve RFIs

Due to the inconsistent nature of email, Preczn strongly advises reviewing and "approving" each RFI message prior to presenting required actions to your merchants- this will ensure your merchant is presented with clear, actionable requirements to streamline the onboarding process. Preczn uses the boolean object actionDescriptionReviewedto indicate that an actionDescription has been reviewed.

You may choose to have an RFI form be created upon your merchants acknowledgement of a required action, this will allow the merchant to make the necessary updates and can be configured to automatically re-transmit changes to Payrix upon saving of the RFI form. Preczn will then automatically send an email to the Payrix risk department notifying them the RFI has been fulfilled and new or updated data is ready for their review.

FAQ