AnsweredAssumed Answered

ExpressResponseMessage Invalid Merchant when issuing CreditCardSale

Question asked by ianwest on Oct 29, 2019
Latest reply on Nov 1, 2019 by kmartin

Like • Show 0 Likes0
Comment • 5

Hi, I'm supporting an existing integration with the ElementExpress XML Api for an ecommerce store. I'm trying to shift the point in our process in which we charge an already created payment account from our ERP system to the store itself.

Everything is working well for both creating the payment account and charging it, against the test service "https://certtransaction.elementexpress.com", however when I switch from the test service to the live service I get an error back after posting the CreditCardSale ExpressResponseCode: 102, ExpressResponseMessage: "Invalid Merchant". So far I haven't been able to find info on what this error means, I found one document that mentioned Invalid Merchant means the card does not support the transaction type "i.e. a travel only card being used to purchase electronics", but I've tried with several standard credit cards that have none of these restrictions.

Does anyone know what ExpressResponseCode 102 signifies? and also if the CreditCardSale endpoint is the appropriate way of charging an existing payment account?

Thanks in advance for your help

<Response>
   <ExpressResponseCode>102</ExpressResponseCode>
   <ExpressResponseMessage>Invalid Merchant</ExpressResponseMessage>
   <HostResponseCode>89</HostResponseCode>
   <HostResponseMessage>DECLINED </HostResponseMessage>
   <ExpressTransactionDate>20191029</ExpressTransactionDate>
   <ExpressTransactionTime>162822</ExpressTransactionTime>
   <ExpressTransactionTimezone>UTC-05:00:00</ExpressTransactionTimezone>

ianwest Oct 31, 2019 6:16 PM

Correct Answer

Hi Kevin,

Thanks for your response! The first link you posted gives me an "unauthorized" page, but I think I'm tracking that the 102 response code is an issue with account setup. Who should I contact with your team at Worldpay to resolve?

I'm actually using different credentials for testing than for live which explains why the process works in testing and not against the live service URL.

Forgive me I'm hesitant to post the live AccountID and AcceptorID publicly, I haven't fully assessed the risk of this yet.

I'll review the COF document, in detail, but in our case the payment account is always being used to process a single transaction, so after my brief scan I don't believe these rules apply.

Based on this quote from the document:

What is NOT considered a Stored Credential on File?

The COF requirements do not apply when the credential is used to complete a single transaction orpurchase.This also includes purchases that encounter shipping delays and backorders, as for example,when multiple items are purchased from an e-commerce retailer and one item is backordered.Themerchant will submit subsequent transactions to fulfill the entire order.Although a returned transactionIDis used, credentials are not stored as required for installment, recurring, cardholder initiated orunscheduled transaction; if the Cardholder returns they would need to enter their payment credentials toplace the order.

I believe the integration is a one off integration for JHarlen.com. I don't believe we are making significant changes, we are simply modifying which of our systems initiates the CreditCardSale portion of the process. Everything from your end though, should be functionally the same.

See the reply in context

No one else had this question

Outcomes

kmartin Oct 31, 2019 5:40 PM

Ian,

Please visit Express_Response_Codes_and_Descriptions 10072019_FIS.pdf for a list of response codes and their meanings. The 102 response code typically indicates an issue with the setup of the account you're using. In the Cert environment, this usually requires assistance from our team at Worldpay to resolve.

To this end, could you provide the AccountID and AcceptorID you're using for Cert testing?

You are correct, use the CreditCardSale method to submit a new charge with an existing PaymentAccountID.

On a related note, I'd also like to point you at another reference document: Express - Credential on File & Card on File (CoF) Overview . This document describes the use of Credential On File (COF) fields to handle different token use cases, in compliance with a mandate from Visa/MasterCard earlier this year. If you haven't already, please review in detail, and include the requisite fields (PaymentType, SubmissionType, NetworkTransactionID) in your integration work.

Lastly, I wanted to ask- which integration are you working with? If you are making significant changes, we'll want a member of my team to be engaged to assist you with this sort of question, and also to help you update the certification when development is complete.

Actions

ianwest @ kmartin on Oct 31, 2019 6:16 PM

Hi Kevin,

I'm actually using different credentials for testing than for live which explains why the process works in testing and not against the live service URL.

Forgive me I'm hesitant to post the live AccountID and AcceptorID publicly, I haven't fully assessed the risk of this yet.

I'll review the COF document, in detail, but in our case the payment account is always being used to process a single transaction, so after my brief scan I don't believe these rules apply.

Based on this quote from the document:

What is NOT considered a Stored Credential on File?

The COF requirements do not apply when the credential is used to complete a single transaction orpurchase.This also includes purchases that encounter shipping delays and backorders, as for example,when multiple items are purchased from an e-commerce retailer and one item is backordered.Themerchant will submit subsequent transactions to fulfill the entire order.Although a returned transactionIDis used, credentials are not stored as required for installment, recurring, cardholder initiated orunscheduled transaction; if the Cardholder returns they would need to enter their payment credentials toplace the order.

Actions

kmartin @ ianwest on Oct 31, 2019 6:48 PM

Ian,

Apologies, the Response Codes document I linked is indeed locked down. Feel free to send an e-mail to the address in my profile and I'll reply with a PDF copy.

Thank you for your attention to the sensitivity of processing credentials. Cert accounts are harmless and can be shared fairly openly; only Production accounts are really a concern. Also, without the corresponding AccountToken, the AccountID and AcceptorID cannot be used. If you'd like to keep your credentials off the website, again, feel free to send them to me by e-mail.

You are exactly correct regarding the COF documentation. For your purposes, you may disregard the COF fields completely.

We would still like to review your work prior to a full Production launch, to rule out any serious issues that might impact the merchant's revenue. Since you're working with a solution that's already certified, we can treat this as a brief "sanity check" where we review a few samples. Since the underlying code is changing, though, we need to do our due diligence. Barring any unforeseen changes, this should be VERY fast and easy.

Actions

ianwest @ kmartin on Oct 31, 2019 7:32 PM

Thanks again for your help Kevin,

I looked in your profile but could not find an email address, what am I missing? I did see an option to download your vcard (kmartin.vcf) but this did not contain your email address.

Here are the requested credentials for the test account

AcceptorID: 3928907

AccountID: 1065455

Understood on the COF document, It is good information anyways as we may someday implement qualifying transactions.

In regards to the review; this is excellent! Once we connect on the contact info I'll send you over the source for our integration.

Actions

kmartin @ ianwest on Nov 1, 2019 9:34 AM

Ian,

I'm not sure why my address is not visible to you- probably something to do with admin permissions on this site. You can reach me at kevin.martin2@worldpay.com. Please send me a note at your convenience; I'll check into your test account behavior in the meantime.

Actions

5 Replies

kmartin Oct 31, 2019 5:40 PM
Mark Correct
Correct Answer
Ian,

Please visit Express_Response_Codes_and_Descriptions 10072019_FIS.pdf for a list of response codes and their meanings. The 102 response code typically indicates an issue with the setup of the account you're using. In the Cert environment, this usually requires assistance from our team at Worldpay to resolve.

To this end, could you provide the AccountID and AcceptorID you're using for Cert testing?

You are correct, use the CreditCardSale method to submit a new charge with an existing PaymentAccountID.

On a related note, I'd also like to point you at another reference document: Express - Credential on File & Card on File (CoF) Overview . This document describes the use of Credential On File (COF) fields to handle different token use cases, in compliance with a mandate from Visa/MasterCard earlier this year. If you haven't already, please review in detail, and include the requisite fields (PaymentType, SubmissionType, NetworkTransactionID) in your integration work.

Lastly, I wanted to ask- which integration are you working with? If you are making significant changes, we'll want a member of my team to be engaged to assist you with this sort of question, and also to help you update the certification when development is complete.
Like • Show 0 Likes0
Actions
- ianwest @ kmartin on Oct 31, 2019 6:16 PM
  Unmark Correct
  Correct Answer
  Hi Kevin,
  
  Thanks for your response! The first link you posted gives me an "unauthorized" page, but I think I'm tracking that the 102 response code is an issue with account setup. Who should I contact with your team at Worldpay to resolve?
  
  I'm actually using different credentials for testing than for live which explains why the process works in testing and not against the live service URL.
  
  Forgive me I'm hesitant to post the live AccountID and AcceptorID publicly, I haven't fully assessed the risk of this yet.
  
  I'll review the COF document, in detail, but in our case the payment account is always being used to process a single transaction, so after my brief scan I don't believe these rules apply.
  
  Based on this quote from the document:
  
  
  
  
  What is NOT considered a Stored Credential on File?
  
  The COF requirements do not apply when the credential is used to complete a single transaction orpurchase.This also includes purchases that encounter shipping delays and backorders, as for example,when multiple items are purchased from an e-commerce retailer and one item is backordered.Themerchant will submit subsequent transactions to fulfill the entire order.Although a returned transactionIDis used, credentials are not stored as required for installment, recurring, cardholder initiated orunscheduled transaction; if the Cardholder returns they would need to enter their payment credentials toplace the order.
  
  I believe the integration is a one off integration for JHarlen.com. I don't believe we are making significant changes, we are simply modifying which of our systems initiates the CreditCardSale portion of the process. Everything from your end though, should be functionally the same.
  Like • Show 0 Likes0
  Actions
  - kmartin @ ianwest on Oct 31, 2019 6:48 PM
    Mark Correct
    Correct Answer
    Ian,
    
    Apologies, the Response Codes document I linked is indeed locked down. Feel free to send an e-mail to the address in my profile and I'll reply with a PDF copy.
    
    Thank you for your attention to the sensitivity of processing credentials. Cert accounts are harmless and can be shared fairly openly; only Production accounts are really a concern. Also, without the corresponding AccountToken, the AccountID and AcceptorID cannot be used. If you'd like to keep your credentials off the website, again, feel free to send them to me by e-mail.
    
    You are exactly correct regarding the COF documentation. For your purposes, you may disregard the COF fields completely.
    
    We would still like to review your work prior to a full Production launch, to rule out any serious issues that might impact the merchant's revenue. Since you're working with a solution that's already certified, we can treat this as a brief "sanity check" where we review a few samples. Since the underlying code is changing, though, we need to do our due diligence. Barring any unforeseen changes, this should be VERY fast and easy.
    Like • Show 0 Likes0
    Actions
    - ianwest @ kmartin on Oct 31, 2019 7:32 PM
      Mark Correct
      Correct Answer
      Thanks again for your help Kevin,
      
      I looked in your profile but could not find an email address, what am I missing? I did see an option to download your vcard (kmartin.vcf) but this did not contain your email address.
      
      Here are the requested credentials for the test account
      
      AcceptorID: 3928907
      
      AccountID: 1065455
      
      Understood on the COF document, It is good information anyways as we may someday implement qualifying transactions.
      
      In regards to the review; this is excellent! Once we connect on the contact info I'll send you over the source for our integration.
      Like • Show 0 Likes0
      Actions
      - kmartin @ ianwest on Nov 1, 2019 9:34 AM
        Mark Correct
        Correct Answer
        Ian,
        
        I'm not sure why my address is not visible to you- probably something to do with admin permissions on this site. You can reach me at kevin.martin2@worldpay.com. Please send me a note at your convenience; I'll check into your test account behavior in the meantime.
        Like • Show 0 Likes0
        Actions

ExpressResponseMessage Invalid Merchant when issuing CreditCardSale

Outcomes

Related Content

Recommended Content