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.
Related
I've gotten a message that my site may be knocked off of Google Merchant Center due to "Inaccurate availability (due to inconsistent availability between the landing page and checkout pages on your website)".
This affects only a small amount of products (only around 0.3% of my 40,000-ish products), so I know it's not an engine issue. After asking Google to recheck the results, they came back with the same error, but with a completely different list of products with no overlap, so I know it's not a problem on the individual product level.
There's no geo-locking on these products, and Google says that the problem exists on US IPs.
Nearly all of the errors look like this:
Value on the landing page - v:out_of_stock
Value in the data feed - v:in_stock
Performing an audit on the products in question shows that none of them have been out of stock for weeks, so the data feed is correct.
None of Google's suggested common issues (geolocking, buy button not working, product can't be shipped to an address, products not available country-wide) seem to apply. The country Google checked this on was a US-based IP.
I'm running out of ideas here, does anyone have any other suggestions?
The answer turned out to be something silly for my site, but I'm posting the answer here just in case this helps someone else.
Google's crawler was setting their country to be Andorra and attempting to check out using the US site. This is obviously not a good representation of the US experience. Google advised us that this was a mistake on their crawler's part, and that we would pass the next audit without any modifications. So if you're here looking for a solution, the absolute best advice I can give you is to find a phone number for Google Merchant Center and give them a call because the error may not be on your end at all.
Update: We passed the audit with no changes made on our part.
I have enabled activation and deactivation feature enabled for License Type = "License Text"
I need the information how many latest activation count are pending, there might be some license deactivated.
I have search API provided by license4j but wont find any exposed API.
Able to get License Quantity but for current activation count not able to see any API.
Is any way to get this information ?
Are you using an own ALGAS? I just take such information out of its underlying database directly if needed. Sorry not being able to help you if using Online.License4J since I'm not aware of such an API function, too.
By the way: License4J team don't answer my questions for weeks now, and you didn't get answer, too, it looks like. Looks like they are unavailable due to unknown reasons. Also, my recently expired ALGAS license has not been renewed to date despite timely payment, which puts me in a bad situation. :-(
I like License4J for its simplicity but that's not that funny actually.
I'm not an accountant, I know almost nothing about XERO.
BUT, I did successfully follow these instructions and now have my Linux box talking to my XERO demo account.
Objective:
My goal is to autonomously parse bank account activity. I want the script to be the first to spot new incoming payments, long before accounting wakes up.
Observation:
XERO seems to consider "Bank statement lines" and "Transactions" two separate things.
I can access "Transactions" with a line like $apiResponse = $apiInstance->getBankTransactionsWithHttpInfo($xeroTenantId);
But I couldn't immediately find a method for "Bank statement lines", worse: I found this page
Questions:
Is this page up-to-date, are "Bank statement lines" not accessible through the XERO-api?
Would anyone be able to recommend another platform, ideally as cheap as XERO, which does allow access to "Bank statement lines" through their api?
I don't believe it is currently possible to access Statement Lines or do any reconciliation via the Xero API.
Their API seems a bit neglected to me, which is a shame because it's a great product.
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 considering asking for credit card details BEFORE an address for a physical product with average purchase price between $10-$50
What might be the technical (or non technical) issues surrounding doing this?
What comes to mind is :
This seems a little non-standard from the users perspective
We cant do address verification if we find we're having issues with fraud (not an issue so far)
Users may be more likely to complete the sale since they've committed to their most important piece of information first
By asking for zipcode we can populate city/state when we do ask for the address
Are there any dealbreakers i'm missing or things I'm not considering?
I'm trying to make the system as flexible as possible, but would prefer to getit right first time without barking up the wrong tree.
My advice to you is don't do it.
I often cancelled buy attempts and abandoned the sites when I got asked for my credit card number right in the face.
Often, the site is so poorly designed with no answers to obvious questions that you have to go through the complete form hoping to find answer in the process. Do they offer this particular shipment option? How much does this cost? Do they send to a package station or only to my home address? Do they provide an extra line for an address for me to use the "c/o" technique? I often could not find answers to these question anywhere on the site. So I either found them in the form before entering my payment details, in very few cases I did call them, in most others I just chose other places to buy from.
One more use case. In many places I've seen they only show you if they have an item on stock on the very last page of the order form. Not many people would want to "commit" to the payment right away without getting all the required information. You enter your credit card number, then on the second page you see they don't offer the shipment option you need, on the last page it says "the item is currently out of stock - delivery awaited in 3-4 weeks". And the order is already placed. Then it is a commitment from the user but not from the company, many will react emotionally to this approach as to scam and request their money back immediately.
The important thing is to behave friendly to your customers, don't scare them away, don't raise suspicions in them, don't make them regret they committed to their buying. Make them feel relaxed and happy and never with their arms bound.
This may seem non-standard from a consumer perspective, but this is perfectly normal in B2B systems. You can collect personal/company & payment details, then shipping & payment addresses, and then present the user with a final confirmation screen showing tax & delivery charges before processing the order. Only then do you process the credit card payment.
However, the issue that "New in town" mentions is a very valid one, where the customer is left thinking:
Hang on, why are you asking for my credit card details when I haven't seen the final amount yet?
I think this is perhaps down to a site not having a clearly defined order creation process (or at least one that is not clearly communicated to the customer), so that the customer is under the impression that by entering their CC details at that point, the payment will be processed there and then.
It may be best to do things the way other popular online stores do, Principle of Least Astonishment and all that, but if you really want to do it in this order then perhaps a simple progress bar to indicate order creation flow would help allay customer fears. Don't bet on it though, online consumers are rightly paranoid when it comes to their credit card details these days. ;)
As someone who has done quite a bit of online purchases, I can say that I would be extremely worried if a site first asks for my creditcard information before it asks for anything else. It tends to trigger my "Fraud Detector". Am not sure why this is, but I just get worried that the site is going to forget about asking for my address.
As mentioned, in B2B environments, this is a bit more common, though. Then again, in many B2B environments, the visitor first creates a business account before he even starts ordering. Part of setting up this business account is providing the creditcard information. To be honest, many B2B also provide services and digital downloads which don't even need a shipping address.
Many people use the ship to address page to determine if the site will ship to their region/country. They are not likely to bother giving CC info before they even know you'll ship to them.
I live in outside the US and MOST sites fail to recognize that there are customers outside of the US. Often the only way to determine if they will ship to me is to go through the order process to find out they have a finite list of "states" they will ship to and no "country" drop down.