Wanted: method to test Decline response

[ss57]

Would like to have a method to force a Decline response while in test mode. It is better to test in test mode than to change to Production mode for testing a form. Some processors even give specific card numbers or dollar amounts to trigger different error messages. This allows for more complete testing of all possible outcomes.

[CnP.Support]

Good day!

To force a decline use the following information:

GUID: a98d7f1d-5801-4115-9105-33e3c1979730
Account ID: 24466
WID: 63850

I understand your point but our issue is integration with several gateways. For each client we have to post the test transactions to the gateway they are set up with. Click & Pledge works with several gateways around the world servicing different countries and currencies. Gateways don't usually offer a decline test account.

We have set up a decline account for this purpose.

Test it and let us know if this works for you.

[ss57]

Is there a certain credit card or CV2 code that I must use to get a decline? 4111-1111-1111-1111 and 111 produce an authorize response.

[ss57]

OK, I got a decline from a card number calculated by http://www.getcreditcardnumbers.com/. Is it possible to get any more information than "response=decline"? I'm looking for information such as "AVS mismatch" or "CV2 error". If this isn't possible through FaaS, is it reported in the back-end anywhere such as portal.clickandpledge.com or Salesforce?

[CnP.Support]

Good day!

The portal includes the decline reason. The test server does not have such response since it is all made up so nothing can match.

In the portal simply download the report and the decline reason is included. The decline reason is exactly as the gateway reports without any change from us.

Hope that answers your question.

[CnP.Support]

Strange..

that account cannot possibly generate an authorize since the info attached for the gateway forces a decline.

Are you sure you used the Decline account information I provided? It requires a miracle for that to respond authorize! hmmm

[ss57]

It seems that there is nothing unique about that Account/GUID combination. I get the same behavior in my own account. 4111-1111-1111-1111 gives Authorize, and other numbers with valid MOD 10 algorithm give Decline.

I know you said the behavior is Gateway-dependent, but I'm not sure I understand that. I wasn't given a choice of gateways. Is that only true in the U.S.? How might I get information about my Gateway. I'd like to know what their messages mean. For example, "No such Issuer" and "Decline for CVV2 failure" make sense, but "Do not honor" is not entirely clear.

[ss57]

I just read your last message again and have a theory. I'm running in "Test" mode, so it probably doesn't even contact the Gateway. My original request was "Would like to have a method to force a Decline response while in test mode." Now that I realize this, it wouldn't be hard to try "Production" mode.

[CnP.Support]

Good day!

That is correct. The account I gave you responds a decline when in Production. In Test mode nothing hits the gateway as we simply process the API response and perform all operations if the post is correct.

In US we exclusively work with Transfirst so you don't have a choice as to which gateway is used. In Canada we use Moneris and in Europe and Hong Kong use Optimal Payment and PayVision. At times we also use Global Payment for certain countries.

Please let us know if we can be of any further assistance.

[ss57]

Thank you. I created a login on the Transfirst website. Haven't found the detail yet, but will press on.

[CnP.Support]

Wait!

Why did you do that? Transfirst works through us and they will not know what you are going to do.

The decline reasons are not really gateway specific- each bank reports its own decline message. "Do Not Honor" decline message you reported before simply means the bank has declined the card - we have seen that through all gateways and is bank (issuing card bank) specific.

Please do not interact with Transfirst as depending on what you say it may totally screw up your account settings. We have seen this before when clients contact a gateway and a setting changes and before you know it all communication fails.

We are your ONLY point of contact and if we think you need to speak with the gateway we will give you a phone number to call.

[ss57]

Wow, I didn't expect to get such a strong response! What could I possibly mess up by contacting Trans First? I had to communicate with them to set up the account, so what's the harm in doing so now? For now, all I want to do is get better reports than are available in the C&P Portal or Salesforce. If C&P provided the information I need to give good customer service, I wouldn't have to look elsewhere. One would think that having established an exclusive agreement with First Data would help you give us better information (e.g. better response messages in the Decline POST data.)

I'm confused. Earlier, you said "The decline reason is exactly as the gateway reports without any change from us." Now you're said "The decline reasons are not really gateway specific". How can it be both?

[CnP.Support]

Sorry for the strong response- it has created major disasters before. We have very specific settings with Transfirst enabling our integration. Agents don't know what is going on and we have had many cases where accounts are totally messed up when clients have worked with TF without our knowledge.

Gateway reports what banks tell it. When an authorization is requested the gateway gets the response from the bank and posts back to our request. So the answer is YES to both- we show what gateway shows us and gateway shows what the bank tells it. The decline reasons are totally up to the issuing bank and what we show as error code 5001 internally with the decline reason saved separately.

Please make sure not to change anything with your setting with Transfirst. We are always worried when clients contact the gateway as we have no idea what will happen.

To give you examples:

• Clients have logged into the gateway's web admin and performed recurring or credit and then expecting us to show that in Salesforce or in our portal. We are integrated with the gateway meaning we post to them for response but they don't contact us when something happens on their servers.
• Clients have logged into the gateway's virtual terminal and issued credit and again calling us inquiring about it when we have no idea what is going on.
• list goes on and on

We simply panic when clients try to work with gateway directly. Hope you see our concern.

[ss57]

I think I understand. Thanks for explaining.

I'll treat my relationship with TransFirst as "Read-Only".