Tag: Google

Musings: 3 reasons if Google Wallet owns the pipes it’ll be a win

By Ashish Datta | Leave a Comment on Musings: 3 reasons if Google Wallet owns the pipes it’ll be a win

Last week, at Google I/O Google announced a set of sweeping changes to their Wallet product. CNet has a decent run down of what they announced but basically it boils down to the ability to “send money with GMail”, Wallet integration into Chrome to decrease payment friction, and “instant buy” with Google+. All in all, the announcements are interesting but I think what’s more exciting is the potential for Google to truly innovate in the payments space.

In the last few years, companies like Square, Dwolla, and Stripe have been innovating in the payments space but they’ve all been reliant on existing credit card infastructure. With the exception of using Dwolla as a replacement for a check, each of the companies still relies on charging a user’s credit card to complete the transaction. I think this infrastructure piece is the key pinchin for Google Wallet. If Google can sidestep the existing payments infrastructure for Wallet, like they did with the telcos for Fiber, they’ll end up redefining how digital payments work.

Ok, so they own the infrastructure now what can they do?

Better risk analysis, lower costs

As far as processing payments go, cost is ultimately one of the most important factors used in picking a processor. The pricing is so opaque that FeeFighters basically built and sold a business simply by explaining in straightforward terms which processor was the best for your business. If Google had the freedom of controlling the pipes, they’d be able to lower their pricing below everyone else by introducing better risk analysis tools into their payment solutions.

Looking at how the APIs from companies like Authorize.net work, they basically only accept the minimum information required to charge a credit card and nothing more. Google would be able to modernize this by incorporating additional “verifying details” about a user to reduce the risk on a transaction. For example, a charge originating from a 2-factor authenticated Google Wallet user that is at their “home” computer is obviously much less of a risk than an anonymous user using a credit card for the first time. By segmenting risk by user, device, as well as transaction type Google would be able to offer the best rates for “normal” transactions and also accept “high risk” transactions.

Give NFC payments some teeth

Google has tried to push out the NFC powered version of Google Wallet in 2011/12 but it was immediately blocked by major American carriers because it competed directly with their ISIS solution. It shouldn’t come as a surprise that the telcos didn’t want to get relegated to “dumb pipes” for payments as well but it’s also not like ISIS has garnered any real traction either.

If Google controlled the entire stack and could successfully convert Android users to Wallet users, they’d be able to essentially pay the carriers “blood money” to lift the Wallet ban to drive adoption and then hopefully reach a more permanent deal.

Ultimately, true mobile payments need to be freed from the existing credit card restrictions and Google could be poised to deliver just that.

Micropayments that work

People have been talking about “easy” micropayments on the Internet for several years but they haven’t really shaken out. Even today, charging someone $1 for something is a huge PITA and it really isn’t even practical. Between fees and long payment forms, the micropayments still aren’t economically feasible.

With Wallet integrated into Chrome and the infrastructure under their control, Google would be able to tackle this head on by reducing the friction to completing a payment and offering different pricing models for micropayments. Think 2 click checkouts for transactions under $5 and a monthly fee of $5 for merchant accounts in good standing instead of transaction fees.

Despite some reservations, I’m excited to see what Google ends up doing with Wallet and how it ultimately influence the payments space. Another big question is what’s Facebook going to do? Revamp Facebook Credits? Start offering co-branded Facebook credit cards?

Anyway, thoughts or comments welcome.

BigCommerce Bulk Coupon Code Importer

By Ashish Datta | 17 Comments on BigCommerce Bulk Coupon Code Importer

A buddy of mine has an eCommerce storefront through BigCommerce, a hosted eCommerce solution. He was looking to run a Gilt City promotion, so he would have to import ~150 coupon codes into BigCommerce.

My friend spent some time looking around for an import codes feature and I would have assumed that a solution like BigCommerce would support a CSV import for coupon codes as well. However, we Googl’ed around a bit and it turns out BigCommerce does not support CSV imports for coupon codes. We stumbled upon this discussion on the BigCommerce forums discussing this shortcoming at length.

On the forum thread, someone had previously developed an iMacros script to automate importing the codes. Unfortunately, I tried using the iMacros script without any success. It looks like BigCommerce has updated the HTML on the page which is breaking the script. Anyway, looking at the iMacro and the opaque syntax I decided it would be easier to whip together a Chrome extension to automate creating coupon codes so decided to move forward with that.

Chrome extensions naturally lend themselves to automating things like this since it’s pretty straightforward to use the background page to maintain any state and hold variables and then use a content script to manipulate the DOM of the page and submit any forms that you need to.

You can grab the extension here http://setfive.com/misc/BigComm Importer.crx you’ll obviously need to be running Google Chrome for it to work.

Also, fork it at https://github.com/adatta02/bigcommerce-coupon-importer

What it does is add a “Bulk Import” button to the “Coupon Codes” page on your BigCommerce site – http://[yourstore].mybigcommerce.com/admin/index.php?ToDo=viewCoupons

If you click that button, a copy of the “add code” form will be displayed along with a textbox. You’ll just need to fill out the form, enter a list of coupon codes you want to create – one per line, and then click “Start Import”.

Your browser will automatically go through and create all your coupon codes. Thats it!

As always, let me know if you run into any issues or have any comments.

Streaming Foursquare checkins with Google Maps

By Ashish Datta | 1 Comment on Streaming Foursquare checkins with Google Maps

This Saturday was the second annual Redline Challenge which is a bar crawl from Downtown Crossing to Davis Square that loosely tracks the MBTA Redline.

This year, we decided to use Foursquare to allow the website to track the position of several of the participants on the challenge. Foursquare natively allows you to track your checkin history with private URLs. Currently, they support a handful of formats with KML being the most interesting for our purposes. You can find your private URLs by navigating to http://foursquare.com/feeds/

We used the Google Maps API along with the KML stream from Foursquare to dynamically place markers on the map as different users checked in to different venues.

Here is the PHP we used to pull back the KML feed, transform it to JSON, and spit it back to our jQuery on the client side:

Pretty straight forward. Here is the jQuery code on the client side to add markers to the map:

That’s about it.

Google Calender embed missing events

By Ashish Datta | Leave a Comment on Google Calender embed missing events

So we decided to use the Google Calendar API in one of our applications to allow users to easily view and export events from outside the app. In general, the API was working well – I was using the Zend library to interact with Google and things seemed fine.

That was until I tried to embed the calendar using Google’s iframe embed code. For some reason, events weren’t showing up in the embeded iframe calendar even though they were showing up in the actual calendar on calendar.google.com. Even stranger, the events were present in a JSON object on the embeded page and they were showing up in the RSS feed for the calendar.

After literally days of debugging and experimenting I finally found out the culprit.

For some reason, events created via the API that start and end at exactly the same time – say a start date of 08-05-2009 10:00:00 and an end date of 08-05-2009 10:00:00 don’t render on the embeded iframe calendar.

What is even more bizarre is that if you create an event via the web interface that starts and ends at the same time, it will render correctly on an embeded calendar.

Anyway, that was weird. All the events without explicit start and end times now last a grand total of one minute.

PS. Kudos to Daum for finding a constant for PHP’s date() function to generate RFC3339 timestamps.

Use like so:

  $date = date(DATE_RFC3339, $timestamp);

To get back a valid RFC3339 for the Google Calendar API.

Google Calendar API create on alternate calendar

By Ashish Datta | Leave a Comment on Google Calendar API create on alternate calendar

A few months ago we integrated Google calendar into an application that we built for a client. Anyway, today I sat down to customize which calendars certain events were being created on. We’re using the Zend Framework’s GData package to interact with Google Calendar and surprisingly the documentation is pretty lacking.

Specifically, I was looking to create events on a calendar that was not the “primary” calendar for a user. After poking around and experimenting, I finally got things to work.

First, you can retrieve the list of available calendars with:

Next, when creating the events pass in the uri and the events will appear on the alternate calendar.

self::$service->insertEvent($event, $arr[1][“uri”]);