Skip to main content

Slash that...Google wallet wasn't the problem.



Update (Friday April 3, 2015) !!

It turns out I wrote this article on the wrong information. Google it turns out is not to blame for the delay the authorizing bank is the source. For what ever reason they flagged the transaction for review (likely the fact that the investor was in Europe when she initiated the request) and that is why the fund transfer to her Google Wallet account and to mine has been delayed. I thus retract the bulk of the comments made below with the mistaken belief that the hold was an internal matter on Google's part. Still the fact that their customer service were unable to clearly specify the source of the block is a big issue that they should address the integrity of their system for review is not relevant as it was not their system that was the cause of this issue. I keep this article up only  as public record of the affair.


So the month starts anew and with it I receive a transfer from my investor at least I am supposed to via Google wallet as initiated by her action…usually this process happens instantly but not this time.

The transaction remained in a permanent state of “pending” for most of the morning and then not wanting to play the role of a nag I asked my investor if she could call Google and check to see what the issue was. This is *after* I called them and confirmed that the issue was not due to a block placed on my account.
She called Google and was told that the reason it was blocked was due to a *random* flag for review that their automated security service engages.

This makes sense and is normal for many banks to provide but what stuck out was the use of the world “random” which my investor confirmed was stated by the rep. It should be clear to any one that having a random review process would make no sense…as it provides a non zero probability that one flags for review a transaction that is completely 100% on board, the optimal process for flagging should apply some type of filter to the criteria of transactions in order to trigger a flag….for example it turns out that my investor is in Europe at the moment and though she has transferred funds from outside of the nation before, that *may* be a consideration in a security flagging heuristic (many banks employ them to ensure fraud is not happening).

However the transaction was not flagged due to any consideration other than a random one which is a failure of the business process, it simply should not work this way…it’s bad design.
Things get more convoluted, apparently the items flagged for review on this random schedule hijack the funds for up to 9 days of review.

Considering that many of these transfers involve fulfillment of contract payments between vendors and customers this is *unacceptable* for any running business to tolerate. Yes, Google indicates that this is possible up front in their terms of service but it is STILL unacceptable as it undermines the very action that many people are using the service for that it was PRIMARILY designed to engage.

Their TOS is akin to having a car manufacturer telling you in the purchase contract that the car they just sold you is likely to lose wheels in mid transit down the road and that the car company is absolved of responsibility …this is absurd and any law that enables such madness is a flawed one (looking at you USG). That said from a business perspective having your funds delayed up to 9 days is just the start of the issues….the funds are in a limbo where neither the SENDER or the RECEIVER has access to them.
How do I know Google isn't making money off of that money in the churn gap (they likely are but aren't paying either of us jack squat for it).

This stinks to high heaven….it is beyond EVIL which Google has expressed is their charter, “don’t be evil” …well Google you have fucking failed on an epic level with this rule.

So what can Google do to aleviate themselves of this evil practice they are currently engaging in??
Well the delay for review is almost certainly due to the fact that what ever automated system they have performing the “random” flags is populating some common queue of transactions and those are then fed to live human agents who then are tasked with making sure that the transaction is valid and not fraudulent…this takes time…however it is very easy for google to set the rate at which such flags are performed (since they are as they say “random”) so as events fill the queue the review team knows the rate at which they are clearing the incidents and for what ever reason set a 9 day max limit on time to review from first entry to system…as I mentioned earlier this is *unacceptable* as users rely on the transactions happening as soon as possible….1 day would be potentially troublesome , 9 days is absolutely absurd.

A single days delay could mean the difference between an on time payment and a late fee assessed for being one day beyond. A single days delay could mean that an account goes into collections….Google has every responsibility to get this done inside a 24 hour cycle…so they can:
HIRE MORE REVIEWERS

If they hire more reviewers then they can shorten the maximum wait time from delays they can arbitrarily hire the numbers required to get the review time down below a day…and solve this problem.
If they reduce the rate at which the random selection is happening they can solve the problem as well.

 As mentioned earlier there is NO reason why the flagging is “random” in the first place that is a flaw that needs to be removed from the system…but beyond that reducing the selection rate would reduce the review rate for customers and that can get it below 24 hours wait.
If they stop random selection entirely and only trigger reviews for transactions that have unique signatures (like a request that comes from a foreign country when a previous history of request were not) they reduce the load of flagged items in the queue and again reduce the time to review.

All of these things can be done by Google NOW to alleviate themselves of these *unacceptable* delays incurred on their users for a service that promises the opposite of what they are delivering when they hold funds hostage for more than one day.

I am hoping some one at Google gets this and puts plans into motion to fix this major flaw in their service. I otherwise enjoy Google Wallet it has replaced a good deal of my banking and I’d love to provide additional advice on how it can be even better but the first is to actually make the service work as people are expecting any banking service to work….anything else is:
unacceptable.
The other side of the coin…
So the customer service side of things was some what reasonable…save for the fact that they could not expedite the solution to the problem.
If it is the case that items from a given day need to be cleared by a given day in the future (up to 9 days in current flawed system) then it means that unless a user calls up to COMPLAIN when they get their money can fall any where in that 9 days…
however
If I am a pissed off customer and I need that transaction to go through ASAP and I take time out of my busy day to call your customer service to express the fact that I need that review expedited then it should be done …
without delay
without excuse
it should be done.
After all the queue of items for a given day is already KNOWN (if it is not known then there is another FLAW in the system design that needs fixing) and it is on this basis that the 9 day guarantee can even be made (think about it) so to then tell me that you can’t reorder my transaction for execution before others who are oblivious and accepting of the delay is basically absolute bullshit.
So when my investor called Google Wallet and told them she needed the transfer to go over they gave her some nonsense about it being still considered for early review….which is again unacceptable. This should not be a decision that any one is reviewing….at this point the users money is in limbo some quantum mechanical state of alive and dead that neither the SENDER of the money nor the RECIEVER can access…how this entire situation is even legal is beyond me….but it is definitely Evil , it is definitely non Google and it definitely needs to be fixed NOW.
If Google needs technical help figuring it out I am a software engineer, I’ve build very complex systems and I can help guide the process give me a ring…or email…or text. I just want my money.
Let me know when you stop being evil in this regard Google and I’ll update this article with new information.

Comments

Unknown said…
I second this post! Give David the entrepeneur his funds pronto or you will be placed on double secret probation.

Popular posts from this blog

the attributes of web 3.0...

As the US economy continues to suffer the doldrums of stagnant investment in many industries, belt tightening budgets in many of the largest cities and continuous rounds of lay offs at some of the oldest of corporations, it is little comfort to those suffering through economic problems that what is happening now, has happened before. True, the severity of the downturn might have been different but the common factors of people and businesses being forced to do more with less is the theme of the times. Like environmental shocks to an ecosystem, stresses to the economic system lead to people hunkering down to last the storm, but it is instructive to realize that during the storm, all that idle time in the shelter affords people the ability to solve previous or existing problems. Likewise, economic downturns enable enterprising individuals and corporations the ability to make bold decisions with regard to marketing , sales or product focus that can lead to incredible gains as the economic

How many cofactors for inducing expression of every cell type?

Another revolution in iPSC technology announced: "Also known as iPS cells, these cells can become virtually any cell type in the human body -- just like embryonic stem cells. Then last year, Gladstone Senior Investigator Sheng Ding, PhD, announced that he had used a combination of small molecules and genetic factors to transform skin cells directly into neural stem cells. Today, Dr. Huang takes a new tack by using one genetic factor -- Sox2 -- to directly reprogram one cell type into another without reverting to the pluripotent state." -- So the method invented by Yamanaka is now refined to rely only 1 cofactor and b) directly generate the target cell type from the source cell type (skin to neuron) without the stem like intermediate stage.  It also mentions that oncogenic triggering was eliminated in their testing. Now comparative methods can be used to discover other types...the question is..is Sox2 critical for all types? It may be that skin to neuron relies on Sox2

AgilEntity Architecture: Action Oriented Workflow

Permissions, fine grained versus management headache The usual method for determining which users can perform a given function on a given object in a managed system, employs providing those Users with specific access rights via the use of permissions. Often these permissions are also able to be granted to collections called Groups, to which Users are added. The combination of Permissions and Groups provides the ability to provide as atomic a dissemination of rights across the User space as possible. However, this granularity comes at the price of reduced efficiency for managing the created permissions and more importantly the Groups that collect Users designated to perform sets of actions. Essentially the Groups serve as access control lists in many systems, which for the variable and often changing environment of business applications means a need to constantly update the ACL’s (groups) in order to add or remove individuals based on their ability to perform cert