Report a Bug

Introduction

From time to time you may run into a problem and need assistance. This is the best practices for getting your bugs to the top of the list and fixed. We need to assign these tickets to engineers, and they will need enough detail to investigate the problem.

Submission

  1. Through the Portal:

    1. https://checkcommercesupport.atlassian.net/servicedesk/customer/portal/1

    2. We suggest you create a login, but you can also submit this anonymously.

  2. Email:

    1. You can always submit a bug report to Support@CheckCommerce.com, or to your relationship manager here. This email does the same thing as the link above.

    2. Sending to a specific person instead of creating a ticket will make your issue harder to track.

The Information We Need

  1. What you are doing ( the steps to reproduce the issue )

  2. What happened

  3. What you expected to happen

  4. Extra Information that is Specific is always helpful. This can include Logins, URLs, Screenshots of the error, error messages, any specific IDs that we need to look at.

What you are doing ( the steps to reproduce the issue )

We need the steps that will reproduce the issue. We want to develop a test case on our side, and investigate. We want to get a description of the system interaction. This often includes the URL you are using and the parameters you are passing in.


Many clients want to express this in terms of their processes. Although this can be good information to have so it can be described in language a client may understand, it doesn’t describe the interaction with the Check Commerce system.

What Happened

What was the response you received back? Was there an error message, if so, what was it? Was there a timeout? What date and time did this happen. What is the information you have back about the thing you are trying to do?


We are trying to collect information there so that we can build a solution to a problem.

What You Expected To Happen

What usually happens, or what is considered a success?

Examples

“We Can’t Save a Login”

From the client perspective, that may be true. But did we describe an interaction between the systems? We described the client system, but at Check Commerce, we don’t know anything about the client system.


If these three items are specific or have enough information, then it’s something that we can work on. Here is an example:

Steps to Reproduce

We are using this URL: https://reporting.checkgateway.com/CheckGatewayService.svc to call the ACH Merchant report. We are using the logins 123456 with our password. We are passing the parameters as
follows:

Parameter

Value

Login

123456

Password

Xxxxxxx ( redacted )

ReportName

ACH Merchant Profile

ExportFormat

CSV

MerchantNumber

123456

What We Expected

We expected to have returned one record.

What Happened

The response was returned without an error, but it contained zero rows.

“We don’t have status updates”

Steps to Reproduce

We are using https://www.checkcommerce.com/EpnPublic/FileDownload.aspx with our Login: 123456
and master aggregator password. We did this last at 1/1/2020 at 2:00 PM MST.
UserId: 123456
Password: <redacted>, the mast aggregator password
Format: TXT
Incremental: False
DateFrom: 12/15/2017

DateTill: 12/17/2017

What We Expected

We expected a file with our statuses to download.

What Happened

We received an error message: “Timeout”

Notes

Other useful information

  • A log file ( when applicable ), or a date and time that you tried this recently

  • A screenshot ( when applicable )

  • Your public IP ( if you want us to search our logs )

  • Your internal ticket number for the issue ( this is only for tracking )

There is lots of other information that might be useful. The more information we can gather, the better the support will be.


Non-useful Information


There are things that aren’t useful when submitting a bug report as well. Here is an example:
An internal reference that we would not have access to. An example of this might be “Checkgateway Error 300”. This message doesn’t come from our system, so we wouldn’t have any information about it, and we couldn’t look it up. The Gateway that is giving this message may put the word “Checkgateway” or “CheckCommerce” in it, but if the message doesn’t originate in our system then we can’t look it up.


Factual Information


Bug Reports should always be factual. We want to get enough information to an engineer so they can resolve the ticket. “We think it’s XXXX”, this is an example of a non-factual statement. It could be good
information, but let’s restate this: “We did Steps 1, 2, 3, 4, 5. We got back message QQQQQ, but we were expecting YYYYY. I think there is something wrong with process 2.” That has a clear order of steps that we could reproduce and is something that is assignable to an engineer.

Search