Implementation FAQ

The Resource Center for fees can be found here.

A video on fees can be found here.

After a Pro Client has signed up for the sandbox environment, the Implementation team will contact them for white-labeling or customized branding parameters and retrieve their colors and logos.

For more information on white label requests and logos, review the White Label and Customized Branding resource.

Sandbox testing is when the implementation group will review your process of boarding a merchant and submitting a transaction. Sandbox is the best place to “play” and learn our system.

Production end-to-end testing is done to see your entire process from start (onboarding a merchant) to finish (running a transaction). This allows our team to verify all system settings are working as expected and we successfully see your API calls (if applicable).

This can be accomplished by creating a token, and in the response receiving the method type. Example below:

method
The method used to make this payment. See VALID VALUES:

Code Snippet:

{
    "customer": {
        "First": "Rachel",
        "Last": "Token",
        "merchant":"t1_mer_61113f7d6a04eab93574291"
        },
        "payment":{
            "number": "4242424242424242",
            "cvv": "123"
    },
        "expiration": "1025"
}

RESPONSE *PARTIAL*
 },
                "payment": {
                    "id": "g157968b6df1534",
                    "method": 2,
                    "number": "4242",
                    "routing": "0",
                    "bin": "424242",
                    "payment": null,
                    "lastChecked": null
},

After you log in, select Reports in the Admin section of the left navigation panel. The Select Report field lists a number of reports that you can select and generate. See Create and Manage Reports for more details.

The Resource center for PayFields/PayFrames can be found here.

PayFrame has limited customization and PayFields is designed to let the customer apply their own look and feel. 

This can be accomplished by using the config field. When sending a transaction using PayFields, you can preset a few config fields prior to the submission of the form. An example of a field wanting to be used when sending a payment is the txns.description field. This field can be preset by sending the description data to PayFields.config.additionalData.description. See PayFields for more information.

In the field configuration section, you will see a list of other fields that can be sent through PayFields.Config.

One of the fields is additionalData, and this field has subfields. The following is the list of subfields that can be included with additionalData:

• discount

• shipping

• duty

• description

• tokenDescription

• txnDescription

• tax

Not at this time.

Terminal transactions (terminalTxn) will only show up under the associated terminal (Merchants > Terminals > Terminal Name > Transactions). The next day when the transaction is imported into Payrix Pro, the txn record will be created and linked to the terminalTxn. The transaction record will then be included in the payment history tab.

The only time you would see a merchant account denied is if the business owner was on MATCH or the information provided did not verify (Owner / DOB / SSN etc). 

What is MATCH? It is a database that houses information about businesses (and their owners) whose credit card processing privileges have been terminated for a set of very specific reasons.

You can update merchant account information through the Payrix Pro portal or through an API integration. To update a merchant’s account information:

1. In the Management section of the left navigation panel, select Merchants.

2. Select the merchant whose information you want to update.

3. In the Account Overview section, click the edit icon.

If a merchant account owner changes, you should inactivate the original account and submit a new one for approval.

This can be done either through the API or a webhook. There is a great article in our resource center here regarding webhooks. Essentially you would set up an alert anytime a merchant account status changed.

Note

alertTriggers determines which resource and event will trigger a webhook. In the case of a webhook that notifies your server when a new Merchant's boarding status updates to (Successfully) Boarded the API resource is merchant (resource 9) and the event is merchant.boarded.

Decline reasons should be dwindled down that are applicable to your clients (i.e. card present declines are different than card not present declines). A few samples would be AVS miss-match (update address) insufficient funds, do not honor (FSA + HSA cards would have this) pick up card (card marked as fraudulent), invalid card number.

Request Idempotency

With this, you can submit a REQUEST-TOKEN within an API request to uniquely identify the request. If the same REQUEST-TOKEN is submitted, your original transaction results will be returned with an additional flag ‘duplicateRequest’ set to true. This prevents duplicate charges and allows you to resubmit requests in the event of a system timeout.

The items factoring into the total amount disbursed from the Payrix Pro portal. These entries form the Disbursement Statement which outlines all associated debits and credits of your account. Such examples of entries include revenue from Captures and eCheck Sales, as well fees incurred such as Interchange.

These are items on the transactional level that outline the activity on the Payrix Pro portal. Where Disbursement Entries will show overall disbursement details, Statement Entries are more granule and will show per transaction data. More resources on Statement Billing can be found here.

We currently do not have a setup where our system will automatically calculate the convenience fee, and add it to the total transaction amount. However, a workaround to this is to create the fee in Payrix Pro and set it as a surcharge. What this will do is reverse calculate the fee based on the percentage provided, and only charge the fee on the calculated amount.

For example, a transaction for $100, with a 3% convenience fee added would bring the total to $103.00. In Payrix Pro, you would set up a surcharge fee at 3%. We will use this fee to calculate that the original transaction was $100, the 3% will only be charged on the $100, and the end result is that the merchant will receive the $100.

More resources on Fees can be found here. For further inquiries, your Project Manager can schedule Fee setup demonstrations with an Implementation Engineer to walk you through it.

You can always contact Payrix Pro Support for more specific queries that can be answered by our support specialists.