Order Processing & Payflow Pro

[Leanne]

Is anyone else having problems with processing Payflow Pro orders through Miva? We are finding that as many as 10% of the orders we process through the admin appear to have been correctly processed but are not being captured by Payflow Pro. A Billing Reference Number is returned in each case, but the number actually belongs to another transaction from the same settlement batch.

[dreamingdigital]

No problems. Payflow Pro was like a rock, even through the super busy Christmas season.

[Leanne]

We thought it was like a rock, too, until we checked our orders and discovered all the duplicate billing references. It's not impossible to work around, but it is worrisome that so many orders appear to have been correctly processed when, in fact, the funds haven't been captured at all.

[Leanne]

I was able to replicate this issue this morning. I submitted a set of 10 orders for processing. 9 of them went through with no hitches, but one of them did not correctly process.

In Payflow Pro, the transaction type is listed as "N" instead of Delayed Capture, the card type is "N/A." No cc or expiry information is listed. The dollar amount of the order is correct, the Approval Code is "0" and the Response Message is Approved. The transaction has a unique transaction id.

The transaction's details show a date and time stamp, the dollar amount, the customer's zip code, the original transaction id, and no other details.

In Miva, the transaction shows as processed, with a billing reference number that is the same as that of another transaction that was processed at the same time.

[cagdas]

Payflow Pro capture request is a very simple message and pretty much the only information it sends is the amount and the reference number. When you search the transaction from the reference number on verisign business center, what do you get? Can you find the transaction? How does it look?

[cagdas]

I'm sorry I should have read your post more carefully. You did say how it looks on Verisign side. As far as I know, N is not a valid transaction type. It doesn't appear in the specifications. It looks like the error is on Verisign end. It may have something to do with their PayPal integrations.

[Leanne]

Thanks for your input, Cagdas. After a little more investigating, here's what appears to be happening.

In Payflow's payment manager, the transaction details for the orders that are not processing correctly (have the "N" transaction type) have the correct dollar amount and zip code (no other information). The original transaction id reported by Payflow for these orders, however, is actually the billing transaction id for another order that is processed at the same time. In Miva, this same billing transaction id is reported as the "successful" billing reference number for both orders, so they both appear to have been successfully captured.

The issue first started after an upgrade to MVM 5.06, PR3 which included an update to the Payflow module. It was only a handful of orders at first, but seems to be getting worse.

[Leanne]

Udpate: Cagdas was kind enough to send me a debug module, which revealed the following:

The correct zip code, transaction id and sale amount are being sent by Miva.

On return, for an order that gets the "N" transaction result in Payflow, the module reports this:

<TransactionResults>
<TransactionResult Duplicate="true">
<Result>
0
</Result>
<AVSResult>
<StreetMatch>
Match
</StreetMatch>
<ZipMatch>
Match
</ZipMatch>
</AVSResult>
<Message>
Approved
</Message>
<PNRef>
BILLING REFERENCE ID FOR PREVIOUS TRANSACTION
</PNRef>
<AuthCode>
AUTHCODE FOR PREVIOUS TRANSACTION
</AuthCode>
</TransactionResult>
</TransactionResults>


I've contacted Payflow -- guess we'll see!

[cagdas]

Thanks, Leanne. Let us know how it turns out.