MIGS Virtual Payment Client - Transaction declined - content-management-system

I am testing MIGS Virtual Payment Client on a test account. When I select payment, I am directed to the Payment Server page where I can choose between Visa and MasterCard. I have been given the following test data in the MIGS manual:
I use 123 as CSC value. However, the transaction always fail with
vpc_VerStatus=E
vpc_TxnResponseCode=2
vpc_Message=Declined //for Visa
vpc_Message=The+card+holder+was+not+authorised.+This+is+used+in+3-D+Secure+Authentication. //for MasterCard
By the way, if I select MasterCard, I am prompted "Please enter your OSID or the last 5 digits of your NAB ID" and a Credit Limit. I use OSID with value 123456 and Credit Limit 10000 respectively. (These are values I entered by myself as I was not given information what to input there).
I had a look at this Commonwealth bank and MIGS Virtual Payment Client error code but it does not solve my problem.
Any help why the transaction is being declined?

Okay, there's a handful of things here you need to understand/check out.
1. Ensure the transaction value ends in $xyz.00 or it will always decline
MIGS behaves differently in TEST and PROD. In TEST, MIGS uses the "cents" portion of your test transactions to determine what response code to return, NOT whether you have correctly provided the necessary data for the transaction. These cents values are as follows:
$ XXX.00 returns "0 Transaction approved"
$ XXX.10 returns "1 Transaction could not be processed"
$ XXX.05 returns "2 Transaction declined - contact issuing bank"
$ XXX.68 returns "3 No reply from Processing Host"
$ XXX.33 returns "4 Card has expired"
$ XXX.51 returns "5 Insufficient credit"
2. Disable 3-D Secure
It looks like you're also getting caught by 3DSECURE, also known as "Verified by Visa" and "Mastercard SecureCode". Call your acquirer/bank and ask them to disable this in TEST and Prod. Why? Invariably when this goes live, your customers will see a screen they are not expecting that asks for more information and then either pick up the phone and ask you to "fix it" or (even worse) leave your store thinking it's fraud.
Because 3-D secure has such low takeup, even most bank support staff don't know about it. Just today I had one of my clients call me about this "issue". One of their customers had called their card issuer to enquire as to what this "Verified by Visa" screen was. The bank (a major Australian bank) helpfully told them it was probably fraud and to not buy anything from that site.
3-D secure has such low penetration in Australia I'd suggest the only outcome of having it enabled is to reduce sales. Don't use it.

Related

BitCoin senttoaddress - those damned fees explained?

I have two testnet nodes set up at home.
I'm testing sending between them, all communication is working just fine!
I just tried to send 0.0003 from A->B
This is my tx:
https://live.blockcypher.com/btc-testnet/tx/dc7a9ba7e01efe04ae6b757d1832d4287b95105f6a1e88eb314a926919d1c32b/
I used sendtoaddress and set the receiver to charge the fees. (5th argument set to true)
I'd created a new address: 2N8yYvrbAxKm9nhS8fDCZng1GRVwvxhUy8n
on Server B seconds before using that new address to send from A->B
How can I find out more about why I was charged
0.01010081 BTC to 2N3HvqWY8sQ59mqHDXeWAd6tV8LWR7pmNnY
I assume this is the wallet of the node that validated the transaction?
I'm using jsonRPC and here is my call:
sendtoaddress(
'2N8yYvrbAxKm9nhS8fDCZng1GRVwvxhUy8n',
'0.0003',
'test from local to MT',
'Message for MT to see?',
true
)
rawtransactions confuse me I'll be honest.
I'm assuming that I need to get over that, but before I do, why was I charged a fee many 100% higher than my transaction?
Cheers!
The output to 2N3HvqWY8sQ59mqHDXeWAd6tV8LWR7pmNnY is your change.
Bitcoin tracks money in a way similar to physical cash. Your balance is composed of many individual outputs, each of a specific value, similar to how your physical wallet balance is composed of many individual notes, each of a specific value (for example, someone with $25 in their wallet might have $20 + $5 in notes).
When you spend Bitcoin, you must consume an existing output in full. As it is uncommon for someone to have outputs that sum up precisely to their desired send amount + fees, any left over value from the outputs used by the transactions are returned to an address in your sending wallet as change.

"Number is too long" error using Invoicing API

I was helping a customer figure out an issue and creating test invoices in the sandbox.
After the 4th one I started getting this error:
{
"name": "BUSINESS_ERROR",
"message": "Number is too long.",
"information_link":
"https://developer.paypal.com/docs/api/invoicing/#errors",
"debug_id": "2ca1d32e1fed3"
}
What number is too long? I've tried looking through all the info and nothing appears too long our out of spec.
Hopefully somoene at Paypal can use the debug ID to track this. This test program has worked without issue for months.
So, after dealing with PayPal support the number that is too long was the invoice number.
When I started my testing in the sandbox I always had PayPal auto-generate the invoice number. It gave something like:
INV2-UR7F-35N45-DGQZ-BYDE
So, after a few tests, the invoice number was incremented (by PayPal) and eventually reached:
INV2-UR7F-35N99-DGQZ-BYDE
Now, on one more call the invoice would be incremented to:
INV2-UR7F-35N100-DGQZ-BYDE
Which is 26 characters, and the maximum length for invoice number is 25.
The solution? I was told to use smaller invoice numbers. ;)
I feel this is a possible bug in the auto-incrementation of the PayPal Invoice, but I am posting this so when others run into this they know what to do.
What I did was in my sandbox account call the Create Invoice Draft API with an invoice number like "Test001" so that there will be plenty of increments left in the invoice number. After that call there should be no need to supply an invoice number, at least for a very long time.

PayPal - DoExpressCheckoutPayment - Validation issue

For Every PaypPal interaction we Do:
1.SetExpressCheckoutReq
2.GetExpressCheckoutDetailsReq
3.DoExpressCheckOutPaymentReq
I do create a billing agreement first and only on scheduled/subsequent orders we use this billing agreement for reference transaction.
Our Issue is:
With a new PayPal account (testpaypal#abc.com) DoExpressCheckoutPaymentReq failed for CITY = SuttonsBay, with the address validation error “10736” (Shipping Address Invalid City State Postal Code) for a user (USER A). And this was corrected in the subsequent request as Suttons bay.
But the same PayPal account(testpaypal#abc.com ) used for the second time with a different user (USER B) on the site, DoExpressCheckoutPaymentReq call succeeds for the wrong CITY = SuttonsBay and allows us to complete the order.
It is to be noted that on all scheduled order of the user, we use the DoReferenceTransactionReq, which has strict validation and this fails every time, esp. for the second scenario described above.
I would like to know why there are inconsistencies in Shipping address validation for DoExpressCheckoutPayment. It is because of this difference that our scheduled orders fails (as described in scenario 2 that allows incorrect address)
Do we any way to have strict Validation in DoExpressChecOutPayment - which solves our purpose?

Why do we have to repeat the fields in DoExpressCheckoutPayment while they were already set in SetExpressCheckout?

Why do we have to repeat the fields like L_PAYMENTREQUEST_0_NAME0 or L_PAYMENTREQUEST_0_DESC0 or PAYMENTREQUEST_0_DESC or even PAYMENTREQUEST_0_AMT in DoExpressCheckoutPayment if we already set them in SetExpressCheckout? Shouldn't they be stored in the session that we've created in the first step?
SEC simply prepares the system for a checkout and gives you a token. Much could change between the SEC and the DECP call, so it's left up to DECP to finalize everything.
For example, with SEC you might pass a shipping address, but then during checkout the buyer changes it to one of their PayPal addresses. Then when you call GetExpressCheckoutDetails you'd get back this address, so then the system wouldn't know which one you wanted to actually include with the order. It would use whatever you pass into DECP.
Same with tax information, shipping, etc. which of course adjusts the final amount, too. Maybe you don't have any address during SEC so you have to wait for GECD to get an address and calculate shipping and tax based on that. Then the values for those parameters and the total would be different between SEC and DECP.
Those are just a couple of examples, but again, there are lots of things that could change between SEC and DECP depending on your application, so you just need to make sure that whatever you want to be included in the final payment details is included in DECP.

paypal checkout with mixed billing type products

I have, in my opinion, pretty complex order case to implement. Paypal was choosen as a solution, but I can't figure it out how to implement it properly using express checkout (or anything else, but I am not sure what is proper to use).
Final order that can consist of (most complex example here):
subscription A with 1 month free trial - 100$/year
subscription B without free trial - 200$/year
initial payment for entire order - 50$
Requirements:
start of the whole order can be postponed due to some factors (I can set PROFILESTARTDATE to the given date)
all subscriptions in the order can be either monthly or yearly, so case where subscription A is paid per year and subscription B per month IS NOT ALLOWED
whole order must be processed in one paypal redirect (paypal page with products listed where client can login to confirm the order)
My problem:
in that order subscription A starts 1 month later than B but I can only set one PROFILESTARTDATE
I could use TRIAL*** parameters (like TRIALBILLINGPERIOD) for subscription B but I can only set one such parameter per paypal request for express checkout, so same problem as above
What would be a best option for such case ?