In late August, I updated my store to version 7.8.7 and was advised I should also update the paypal checkout method to improve security, which I did.

My retail customers place and pay for their orders online, by either using the regular store checkout or using PayPal Express checkout. Many of my custom and wholesale customers provide credit card (CC) info when placing orders by phone or mail. I enter their CC info later, when their order is done, to create a "card not present" transaction for their order.

The first few weeks after the updates, my store seemed to work pretty much as it did before the update. Things changed this week, however, when I have tried to process CC payments for my custom and wholesale orders.

When a custom or wholesale order is complete and ready to ship, I logon to my store, create an order, and use the store's regular checkout process to enter the CC information. This has been working smoothly for years.

Things changed this past week, however. For some payments -- about half I've processed this way -- I hit a major snag. After entering my customer's credit card information, a popup window appears that says a verification code has been texted to my customer's phone.

This code needs to be typed into a box in this popup window to finalize the transaction. Problem is the box is on my computer screen and the code is on my customer's phone.

The only way for me to get that code is to call my customer and hope they answer in time before the verification code expires.

I contacted Paypal customer support a few days ago. They advised me to log onto Paypal and set up a separate "virtual terminal" transaction to get paid. While this would get the job done, this isn't, IMO, a feasible way to routinely handle "card not present" transactions.

Here are the settings I'm currently using for PayPal in my Store Admin: Orders Admin: Payment Providers -- https://classicbells.com/currentPayPalSettings.jpg

Thanks for your help and advice, everyone! --DeeAnna


Classic Bells, Postville, Iowa, USA, https://classicbells.com/

Hi DeeAnna
But wouldn't that code be part of the 3DS authentication which will be becoming more and more widespread? It sounds like PayPal have their methods for you to charge a customers card but if you are processing a transaction on the customer's card you are going to have to go through the same steps that the customer would have to go through or the bank may reject the transaction anyway as it doesn't have the 3DS challenge / response result.
What are the problems with using the PayPal Virtual Terminal which is the way I thought these transactions should be processed?

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

I used to use VT in the early days when I didn't pay $30 per month to PP to be able to process credit cards on my website.

Paypal's Virtual Terminal is a separate system that isn't connected to my store's order database. I log onto PP separately, enter the card and customer info in VT, and process the payment there.

A payment made via VT does not interact with the store's database, so the order info in the store has to be manually updated to reflect payment is complete.

In essence, what has been a smooth operation turns into a multi-step process on two different websites. The customer's experience won't change if I have to use VT, but the benefits to me of processing "card not present" transactions using the store's checkout process is pretty much gone.

Classic Bells, Postville, Iowa, USA, https://classicbells.com/

I dug into this more this afternoon and learned what I have long been doing is a "merchant initiated transaction" (MIT). I gather it is theoretically possible to complete a transaction using the ECT ordering system if certain requirements can be met. It's beyond my paygrade, however. I reluctantly made an acquaintance with ChatGPT, and it explained the situation like this:

"...The first transaction is when the customer is present. They authenticate (maybe 3D Secure), agree to let you charge them later, and you store a payment token (“billing agreement / vault token”) — that’s your “key.” Later, you use that stored token to charge (initiate) without needing them to actively authenticate each time. That’s a merchant#8209;initiated transaction (MIT).

Using PayPal in the US, here’s what you do (and PayPal infers from your actions):

Set up a Billing Agreement (or Express Checkout + reference transaction support)

During checkout (while the buyer is present), you run an API call to create a billing agreement. This tells PayPal: “This buyer agrees that I may charge them later using stored credentials.”

PayPal gives you back a BillingAgreementID that represents that permission/agreement.

Later, when you want to charge (merchant-initiated), you call the API DoReferenceTransaction, passing in that BillingAgreementID or a previous transaction ID. That’s how PayPal knows it’s a “merchant-initiated” charge (you’re not doing a fresh buyer-present checkout).

Because PayPal sees you’re using a stored agreement, it treats it differently than a regular checkout and does not force 3D Secure again (unless something forces it, e.g. issuer request).

In the request, there is a field called PAYMENTINITIATOR which can be CUSTOMER or MERCHANT. For MIT, you’d use MERCHANT.

Also, there’s a CARDONFILE field: it might say FIRST (when storing) or SUBSEQUENT (later charges).

You also reference a prior transaction or billing agreement (“previous transaction reference”) so that PayPal sees there’s a history...."

Classic Bells, Postville, Iowa, USA, https://classicbells.com/