This is a very basic tutorial on dealing with Payeezy, who’s documentation I found sometimes difficult.  Some of this guidance, I only found in forum threads and so I document…

Get What You Need

1. Merchant Demo account
2. Developer Sandbox account
3. Merchant Token (demo)
4. API secret (sandbox)
5. API key (sandbox

Merchant Demo Account

To get set up, you’ll have to run through a demo process and have successful API calls to a sandbox account.  After you successfully make calls, you’ll have to get in touch with Payeezy Developer support and ask them to “onboard” your real merchant account and then run through the same process below, but setting up your API as “Live” instead of “Sandbox”.

So, first, lets start with setting up a demo merchant account.  Simply sign up here, fill in all the information and you should receive a username and password.  They often request you change password on first login.

You will be needing information from here in order to set up your merchant token in the Developer Sandbox.

Developer Sandbox Account

Click here to sign up.  This should also be instantaneous.

• Login
• Go to “Merchants” menu option
• Click on the “Sandbox” button
• Hit the “+ Add a Demo Merchant”

Merchant Token

To get the merchant token, use the information from the Merchant Demo Account you logged into (follow the instructions closely under each field as shown in picture.

The instructions are solid, the only slight bump is that you will have to delete the HMAC key and create and copy a new one (since this is your first time logging in – you don’t have the old one).   Create it, copy/save it, go back to sandbox and submit the form.  You should be taken to a screen listing all the merchants in your sandbox.  Your Merchant token is listed in the 3rd column, copy and save.

API Key / Secret

• From the sandbox menu on top, Select “APIS”
• Click on the Add New API button
• Enter any name
• Select “Sandbox”
• Submit

Once done, you’ll be taken to your new API.  Click it and you should have the API Secret and API Key listed.  Also copy and save.

Get Coding

First, it’s difficult finding a Direct API example in .NET / C# off of Payeezy’s documentation, but there is a thread that has helpful examples.  I followed these examples as well as copied the one I found most useful into file TestPayeezy() in case it ever gets deleted.

All the below code can be found on my GitHub: https://github.com/catriname/CheckPayeezy

Basic Models

From this point, I created a basic form, and before showing it to the user, I retrieved the user profile information to auto-fill basic billing address information.  This is my PrePayment View Model.

Then, I created a Check Payment View Model that includes the previous prepayment information + new check information.  This I passed through controller to the SendToCheckAPI.

All the models under Check are created to populate one transaction and are created and named so that when the Transaction model is serialized (JsonConvert.SeralizeObject())  it will match the format required by Payeezy.

I also created a CheckReponse model to handle the API’s response, again using their documentation so that a simple Json.DeserializeObject will read the response.

Looking Closer at SendToCheckAPI

For this, I simply used the examples provided in TestPayeezy().  The only difference is that instead of using StringBuilder to build my JsonString, I created a transaction object, serialized it, and then ran it though the CreateHMAC method.  I deserialized the response into a nice clean CheckResponse object and quickly scaffolded a View off this model so that I could immediately view the API response.

For testing data, I went to this Payeezy link and used the name, routing number, account number, check number, customer id, customer id number that are in the JSON on left hand side.

Some Gotcha’s

If you keep getting “400 Bad Request” do not assume there’s something wrong in your headers, etc.   My original tele_check model included fields that I did not populate, therefore filling with empty strings and null.  This caused repeated “400 Bad Request” responses until I removed / commented out those fields from my object.  Give it a try if you are not successful at first.

More on this, when we went live we had difficulty with “check_type” and whether it was a “P” (Personal) versus “C” (Commercial).  The required fields for Commercial seem to be a bit more sensitive.  We went first with Personal, it worked just as demo did, and then fine tuned the required Commercial fields and their values with help from Development support.

Another problem when we went live was “customer_id” and “customer_id_number”.  I had a lot of difficultly finding exactly where this property was listed and it IS required.  For reference, the int values are 1 = Driver’s License, 2 = Social Security, 3 = Tax ID.  My form field placeholder says: “DL: TX12311145 / No dashes in SSN or TAXID”