During testing of tokenization when we supply a postal code with a card we get
attribute postal_code_check passed
The documentation states "Supplying a postal_code during tokenization initiates the AVS check."
So in our live marketplace, can we verify AVS as part of the tokenization process or does the testing environment nor match the live one?
To give an example; when I tokenize a card and then check the card object I can read
postal_code_check: passed
security_code_check: passed
I know the security_code_check should not be getting done until an "authenticated operation" is performed so it should not be happening here, worrying. Where as postal_code_check may be "initiated" during tokenization.
In a test environment, Balanced does not call out to the credit card networks at all. Therefore, it cannot verify postal codes or CVV. Please look at https://docs.balancedpayments.com/1.1/overview/resources/#test-credit-card-numbers, which provides test credit cards numbers for simulating different scenarios.
Related
I'm currently evaluating using Plaid or Yodlee for transaction aggregation (I'm using the Dev environments for both right now). I really prefer almost everything about Plaid, but I'm having trouble with transaction name/description. Yodlee has a data field called the "simple description":
From their docs: "The transaction description that appears at the FI site may not be self-explanatory, i.e., the source, purpose of the transaction may not be evident. Yodlee attempts to simplify and make the transaction meaningful to the consumer, and this simplified transaction description is provided in the simple description field."
I'm displaying the transaction name to my end-users and I'm looking for something more user friendly than the transaction name field which often returns strings like "Withdrawal Check Card MOE'S BROADWAY BAGE BOULDER CO Date 01/06/19 0 9006020339 0 5812 Card [XXXX]".
I'm sure I'm not the first plaid customer to have this need. How do Plaid reliant apps solve this problem?
Plaid doesn't offer a simple description field as far as I know, but they do clean up transaction names.
I've found that when a new pending transaction comes in, the name is messy like you mention (e.g. UBER *TRIP 5VVB2). But once the transaction is confirmed, Plaid normalizes it for common merchants (e.g. Uber). I don't know why Plaid doesn't offer this normalization for pending transactions, but I have brought it up with them before. Perhaps this is something that could change in the future?
A solution, albeit complicated, is to build a custom model that normalizes transaction names. That's what we are doing at Pluto Money to supplement Plaid's transaction data.
I received a direct response by email from Plaid Support:
Thanks for reaching out to us here on Plaid Support, I'm sorry about
our delay.
Our name field for each transaction represents our best effort to
balance detailed transaction information while providing a clean and
consistent API response. This behavior does vary across banks, both
due to bank behavior and our own integration quality. Generally at
larger banks our integrations do a better job at returning clean
transaction names with appropriate transaction detail but for some of
our smaller banks transaction names may be more "raw".
If you never want additional detail beyond the merchant/transaction
name in your app I would encourage you to implement some filtering on
Plaid's name field to make sure that no date- or account number-like
character strings pass through into your user facing stream.
I'm trying to place API calls to charge shoppers in BlueSnap's Sandbox - using a simple Auth-Capture call and I'm not sure which test cards I can use:
<credit-card>
<card-number>4263982640269299</card-number>
<security-code>837</security-code>
<expiration-month>02</expiration-month>
<expiration-year>2018</expiration-year>
</credit-card>
I'm looking for reference on:
1. Can I just use any test card I find on Google?
2. Can I test card failures somehow?
3. Do online wallets work with the same type of cards?
I asked BlueSnap's Support team and this is what they say:
It doesn't matter if you use API or not - also the BlueSnap console (UI) allows using test cards.
Sometimes you can use Google to search for test cards - but if you're testing with BlueSnap, the best option is to use this page for reference.
The provides you with different card brands & currency scenarios and also you can choose specific cards to get the result you want (success or failure).
Be sure to scroll all the way to the bottom and see the Apple Pay test cards - for other wallets you can keep on using the cards at the top table.
We are wondering if in Hotcakes 1.10.3, if the shipping method lookup can recognize if an address entered is a P.O. Box before returning available shipping methods.
Why we ask - our client is primarily using FedEx to deliver shipiments, but would like to default to USPS shipping methods when a customer enters a P.O. box as FedEx doesn't deliver to P.O. boxes.
I've tried out a few PO box addresses, and in our current build FedEx rates still get returned. Is there any way to block FedEx from returning if a P.O. box is entered as an address in Checkout?
Thanks much.
Disclaimer: I work for Hotcakes.
I looked at this in our code base and it was interesting to see that we're simply taking the address entered by the customer in checkout and passing it directly to the shipping provider (e.g., FedEx). In my testing using FedEx specifically, they're returning rates from their own web service, regardless to whether the address is a P.O. Box or not. They don't seem to be checking for this themselves. I didn't check the other built-in live rate providers for this answer.
I order to workaround this, you can detect this yourself and prevent this from happening in your custom viewset. However, you should be aware that doing this would really require that you test all of the use cases that you expect for your target customers to fall into on your site.
In your viewset, find the Checkout.js file in the Scripts folder.
In this file, you'll want to look for the following method and apply a check to see if the Address 1 field is a P.O. Box or not. If it is, remove the FedEx rates from the list of shipping providers that received rates. This will prevent your customer from selecting unsupported rates.
RefreshShippingRates
An example of that check in this JS file might look like this:
var address1Value = $('#shippingaddress').val()
if (address1Value.substring(0, 4) == "P.O.") {
// iterate through each rate to see if it needs to be removed
}
I want to perform rigrous testing on Payment Gateway(2checkout) and Pay Pal. For testing, I need to simulate a large number of successful, failed and halted transactions (transaction stopped due to system crash/reboot). But I don't want to make actual payments.
1. Is there any way I can make a test transaction on payment gateway, using fake card numbers or something else.
2. What are the possible advance testing scenarios for Payment Gateway testing?
For example:
Changing the amount, unmask CVV or card from Inspect
element.
List item
There are two options :
Using the PayPal Sandbox (Application Testing), or
Using Dependancy Injection (Unit Testing).
Both would work but I would suggest a Dependancy Injection approach. Assuming you have a separate object that only interacts with PayPal and then other objects that do your actual application logic (and error handling, etc) then you can just create a dummy version of the PayPal interaction object (that always returns true, or conditionally returns false, whatever) and then test your various application classes in detail.
I would suggest you only one solution, look at this Git PayPal-Android SDK and go through the README.md file. Last link tells you how to create a sandbox PayPal account to create dummy transactions across your sandboxed account developer account.
If you have doubts, you can refer Part 1 and Part 2 of AndroidHive tutorial for this.
One of our users is getting an error when they attempt to make a purchase and I'm trying to identify why this is occurring.
The message returned from PayPal is:
<Errors xmlns="urn:ebay:apis:eBLBaseComponents">
<ShortMessage>Transaction refused</ShortMessage>
<LongMessage>This transaction cannot be completed because it violates the PayPal User Agreement.</LongMessage>
<ErrorCode>13122</ErrorCode>
<SeverityCode>Error</SeverityCode>
</Errors>
This product is working for other users, just not him.
Obviously it's violating the User Agreement but I'd like to identify why.
UPDATE
The users that are affected by it seem to all have one or more of the following: a non-UK email address, a non-UK PayPal account or a non-UK payment source.
We've not had a resolution yet, but have directed several users to contact PayPal directly. The feedback we've had is as follows:
"I tried with another paypal account, that failed too, despite being able to use both PayPal accounts to pay for other services."
"PayPal are aware of the error message, but they simply cannot explain why it's happening. After an hour on the phone with them today, they seem incapable of tracing the reason for this error."
Needless to say we've got some very frustrated users.
I had similar problem... Title of our item we were selling was:
Inc. Special Offer: <<Famous author>> eBook for only 10.00$
When we changed the title to something more descriptive, everything was OK
Did you open a ticket with MTS or call the Business Support line? If you did open a ticket can you please give me the ticket number? I'll take a look at it.
It may be something that you need to address with Business Support though.
I had this same error coming back for one of our customers and I had the same issue as #knagode with my product name.
For some reason "Dark Havana" in the product name set this off and produced this error. If I ever hear back from Paypal on why this phrase is not acceptable, I will circle back and edit this response.
It turns out that the value in "PaymentDetailsItem - Name" was one part of the problem. We didn't have any special characters (or so I thought) in there, just "product name: person name". When I spoke to PayPal support their response is as follows:
"I have checked it, it's a combination of many things that we cannot disclose.
However removing the ":" before the name PAYMENTREQUEST_0_NAME should work.
Can you send PAYMENTREQUEST_0_NAME=xxxx USER NAME
Instead of PAYMENTREQUEST_0_NAME=xxxx : USER NAME"
Once I had removed the ":" from that field, it started working again...bizarre!
This error still gets triggered with non-UK PayPal accounts but happens less frequently now.
For any others investigating this issue please be aware that PayPal has filters in place that looks for globally specific geographic terms. If any terms used in the product description trigger the filters, the transaction could be refused. In our case, we are online rug retailer with many of our products ranging across the traditional rug spectrum. We found that any rug with the term "Persia" in the title were being refused due to economic sanctions against nation states associated with that term.
The filters are not geographic only and other controversial terms could also trigger the filters to refuse the transaction. In one instance, we had a rug with "Confederate" in the product description that also triggered the filters.