Supported credit cards

[webteks]

Hi,

I notice all the standard gateways in able support visa, mastercard, american express and discovery.

Being based in the UK I very rarely have a request for american express and I have never heard of discovery before.

The supported options I need are:
Visa
Visa Debit
Mastercard
Switch
Maestro
Solo

Is this configured in the payment gateway or somewhere else?

Thanks

[Logan Rhodehamel]

We used to support Switch/Solo/Maestro through our LinkPoint integration. But they released a new version of their API that no longer supported these payment instruments.

I will investigate whether any of our existing gateway integrations have support for them.

All of our gateways support mastercard / visa.

[webteks]

Thanks, these cards make up around 30% of my transactions so it is very important for me.

[webteks]

Hi Logan,

I am still waiting for a reply to this. I have hired a developer to design the payment gateway and we have got as far as we can on it. It seems that its not possible to add switch and solo cards via code in the gateway as it seems there are set methods that only allow the following:

Visa = 1,
MasterCard = 2,
Discover = 3,
AmericanExpress = 4,
JCB = 5,
Maestro = 6,
PayPal = 7,
PurchaseOrder = 8,
Check = 9,
Mail = 10,
GoogleCheckout = 11,
GiftCertificate = 12,
PhoneCall = 13,

What should we do next? I really need to be able to take these cards as they are extrmeley common in UK.

[Logan Rhodehamel]

Developing this feature was problematic because we did not have a way to test. I realize these cards are very frequently used on your side of the pond.

My understanding of the Switch/Solo/Maestro instrument is they are all debit cards, and all are owned by the Maestro brand. This is why I did not add separate PaymentType for switch or solo. This field is primarily used to determine which payment form to display.

Do you think it would be acceptable to use #6 (maestro) for these card types for the time being? That field primarily is going to drive what payment form is shown to the customer, and in this case I think the form will be nearly identical for these types of cards.

[webteks]

yeah if it works by putting them through as maestro its all good with me. Thanks for getting back to me

[webteks]

Sorry to be a pain but I've got another problem. My payment processor distinguises between visa and visa debit. How would we go about accomodating for this in the gateway?

[webteks]

does ablecommerce support visa debit cards?!?!

[pcgutierrez]

On behalf of webteks, the following link shows all the Payment Method names we need assistance in adding into the "choices" from the Type dropdown list in the Payment Methods admin window (~/Admin/Payment/Methods.aspx):

http://www.secpay.com/sc_api.html#other (please see card_type parameter)

As you can see from the link above, we need the choices Switch, Solo, Delta, and Diners available in the Type dropdownlist.

Technically, we want more items on the enum CommerceBuilder.Payments.PaymentInstrument (e.g., CommerceBuilder.Payments.PaymentInstrument.Switch.).

Will it be possible to do this? Please assist ASAP.

[Logan Rhodehamel]

As you can see from the link above, we need the choices Switch, Solo, Delta, and Diners available in the Type dropdownlist.

I didn't have a quick answer that would be helpful. I will address this today.

Switch and Solo are effectively Maestro. Delta is Visa debit. Diners is effectively MasterCard.

I suppose it wouldn't hurt if we could list them individually. I am just wishing we had made the payment type a table rather than an enumeration in the DLL.

[webteks]

Hi Logan,

We appreciate your help in getting this matter sorted. I know we have been "on the case" so to speak but I thought it appropriate to voice our reasons.

We are based in the UK and before I purchased I read through the forum to see what people were saying about it. I saw a post questioning the shiping system working outside the US which gave me concern about if it would work in the UK especially as it didn't support secpay.

I asked several pre-sales questions via your online website expressing my concern. I was told that to process payments it was a simple matter of creating a custom payment gateway and instruction on this would be provided in the forum.

My understanding now is that extra changes are needed and I am feeling misled. I have incurred development and hosting costs and I am no closer to going live.

We opened a ticket asking for a developer to look at this thread and received this response:

"Please don't open a case asking for a developer to repond to a post that was from a few hours ago."

from Katie. I asked a question on the 31st January, I make that 8 days by my count. I understand that you cannot guarantee a response time in the forums and if I was creating a completely new feature I hadn't been promised then I wouldn't be having a rant right now.

I feel I have been mislead. If when i asked about integrating SecPay they said "You will not be able to support the credit cards your customers want to buy with by making a payment gateway and in 3 months from now you still won't have a live store" then I most definately would not have bought this product.

Most of my development costs for this project so far have been paying a developer to sit around and wait for responses which is acceptable to a point but now seems excessive for something this necessary.

I am at crunch point now. Ablecommerce seems a great product and the features are excellent but if a refund was offered to me now I would take it and write off the development costs as a learning experience.

In truth I do not want a refund. I want the website working and processing credit cards! I can't afford much more delay.

If I buy the source code will that mean we can fix the problem? Won't this just complicate matters when future versions of ablecommerce are released and we want to upgrade?

Can anyone advise me on the best way to get this fixed asap!?

[pcgutierrez]

As you can see from the link above, we need the choices Switch, Solo, Delta, and Diners available in the Type dropdownlist.

I didn't have a quick answer that would be helpful. I will address this today.

Switch and Solo are effectively Maestro. Delta is Visa debit. Diners is effectively MasterCard.

I suppose it wouldn't hurt if we could list them individually. I am just wishing we had made the payment type a table rather than an enumeration in the DLL.

Hi Logan,

That may be the case but the SECPay API (linked on my previous post) requires that if you were to use Visa Debit, it should be specified as Delta instead of Visa. We tried using a Visa Debit card number with the type "Visa" selected and it failed authentication.

I agree with you when you say that this would have been so simple if the payment types were in a DB table instead of an enum in a referenced compiled DLL. However, based on the sample codes of the custom Authorize.NET payment gateway stickied in this forum, the card type is directly derived from that enum thus our own custom-made SECPay payment gateway does the same thing.

That being said, what approach would you recommend in order to meet our immediate requirements?

Thanks!

[Logan Rhodehamel]

That may be the case but the SECPay API (linked on my previous post) requires that if you were to use Visa Debit, it should be specified as Delta instead of Visa. We tried using a Visa Debit card number with the type "Visa" selected and it failed authentication.

Once you get to the payment gateway integration, you can use the name of the payment method to help determine the value that should be passed to the SecPay provider.

The challenge you have is that the PaymentInstrument (the enum) is used to help determine what payment form is displayed at checkout. For instance if switch/solo cards are used, the form would probably contain a field to enter the issue number.

There is only one good interim solution I can offer you. For Visa Debit, Maestro, and Switch/Solo cards you would associate to the "Maestro" payment type. The "maestro" payment form would include the fields required to support any of these payment types. The fields are largely the same, and some fields would have to be optional.

When the payment is submitted, it will pass through to your SecPay integration. The integration will use the payment method name to determine the cardtype value to pass to the processor.

Longer term, I will get the enumeration updated. I have logged bug 6386 to get the missing payment types added. The enumeration will have three new types: SwitchSolo, VisaDebit, and DinersClub. I am pressing to have this in an update available no later than next Friday.

[Logan Rhodehamel]

That may be the case but the SECPay API (linked on my previous post) requires that if you were to use Visa Debit, it should be specified as Delta instead of Visa.

By the way, once the enumeration is updated, it will include "VisaDebit" but within your integration you will translate this value in to the "Delta" card type for SecPay.

I checked the SecPay API docs. I did not believe that Diner's was in use any more but I put that in just to be safe.

[pcgutierrez]

That may be the case but the SECPay API (linked on my previous post) requires that if you were to use Visa Debit, it should be specified as Delta instead of Visa. We tried using a Visa Debit card number with the type "Visa" selected and it failed authentication.

Once you get to the payment gateway integration, you can use the name of the payment method to help determine the value that should be passed to the SecPay provider.

The challenge you have is that the PaymentInstrument (the enum) is used to help determine what payment form is displayed at checkout. For instance if switch/solo cards are used, the form would probably contain a field to enter the issue number.

There is only one good interim solution I can offer you. For Visa Debit, Maestro, and Switch/Solo cards you would associate to the "Maestro" payment type. The "maestro" payment form would include the fields required to support any of these payment types. The fields are largely the same, and some fields would have to be optional.

When the payment is submitted, it will pass through to your SecPay integration. The integration will use the payment method name to determine the cardtype value to pass to the processor.

Longer term, I will get the enumeration updated. I have logged bug 6386 to get the missing payment types added. The enumeration will have three new types: SwitchSolo, VisaDebit, and DinersClub. I am pressing to have this in an update available no later than next Friday.

Sounds good. Would you be able to guide us where we could get the payment method name, instead of the method type, from the AuthorizeTransactionRequest object parameter in Functions DoAuthorize, DoCapture, DoVoid, and DoRefund so we can in a way make up for the downtime this problem caused us?

Following the sample codes provided in the Authorize.NET payment gateway, the card type parameter for the SECPay Web Service Method is currently taken in this manner:

PaymentInstrument instrument = Payment.PaymentMethod.PaymentInstrument;
switch (instrument)
{
case PaymentInstrument.AmericanExpress:
strCardType = "American Express";
break;
case PaymentInstrument.MasterCard:
strCardType = "Master Card";
break;
case PaymentInstrument.Visa:
strCardType = "Visa";
break;
case PaymentInstrument.JCB:
strCardType = "JCB";
break;
case PaymentInstrument.Maestro:
strCardType = "Maestro";
break;
default:
throw new ArgumentException("This gateway does not support the requested payment instrument: " + instrument.ToString());
break;
}

Anyway, thanks for the work-around fix you suggested Logan. Once we try it out ASAP, we'll let you guys know how it went.

Out of topic, since we've already established a fast dialogue here, I'd like to ask for your opinion on how we could integrate 3D Secure into the pre-existing payment processing. In the long run, we need to implement 3D Secure on the normal website browsing customer payment process but still use a non-3D Secure payment process for over-the-telephone purchases within the Admin section.

Thank you in advance.

[Logan Rhodehamel]

I am thinking something along these lines:

Code: Select all

PaymentInstrument instrument = Payment.PaymentMethod.PaymentInstrument;
 switch (instrument)
            {
                case PaymentInstrument.AmericanExpress:
                    strCardType = "American Express";
                break;
                case PaymentInstrument.MasterCard:
                    strCardType = "Master Card";
                    break;
                case PaymentInstrument.Visa:
                    strCardType = "Visa";
                    break;
                case PaymentInstrument.JCB:
                    strCardType = "JCB";
                    break;
                case PaymentInstrument.Maestro:
                    string paymentName = Payment.PaymentMethod.Name;
                    if (paymentName == "Delta") strCardType = "Delta";
                    if (paymentName == "Switch") strCardType = "Switch";
                    break;
                default:
                    throw new ArgumentException("This gateway does not support the requested payment instrument: " + instrument.ToString());
                    break;
            }

Note the extra handling in the Maestro section

[pcgutierrez]

It worked Logan. Thanks!

However, it opened another problem. Is there a way to add another field for Solo and Switch cards for getting issue numbers?

Also, I noticed that when you add another payment option via the payment tab in the order detail within the admin dashboard, there are no fields visible if you choose the Maestro option.

[pcgutierrez]

It worked Logan. Thanks!

However, it opened another problem. Is there a way to add another field for Solo and Switch cards for getting issue numbers?

Nevermind, solved it.