Credit Card Tokenization API and changes to WePay API fees

[Aleksey Sanin]

To Our Partners:

Today, we are excited to announce two major changes in our API:

- Credit Card Tokenization API
- Changes to WePay API Fees

* Credit Card Tokenization API

The Credit Card Tokenization API lets you take complete control of
the checkout experience (no iframes or redirects) without requiring
you to handle or store credit card information in your environment.
To learn more about the new API, read the tutorial:

https://stage.wepay.com/developer/tutorial/tokenization

* Changes to WePay API Fees

We are changing WePay API fees to be 2.9% + 30c (no minimum) for all
new applications. We would be happy to apply the new fees structure
to any existing application on production or stage, just shoot us an
email to a...@wepay.com with your application ID and we will make the
change in 1-2 business days.


As always, we would love to hear from you at a...@wepay.com and would
be glad to answer any questions you might have!


Best,

Aleksey

--
Aleksey Sanin
WePay | VP of Engineering

[Jon Stevens]

Sweet! I love the idea of getting rid of that iframe. =)

I'm curious... what is the point of set_endpoint? Can't you just infer
that from the .js load location (ie: it came from stage... or
www....).

Also, I have some fears around the way that the .js file is loaded.
For example, what happens if WePay is down or the client can't connect
to your networks for some reason? With a sync load like that, it will
block my page and there is no way for me to recover. I'd have to write
my own async loader around your JS. I'd love it if you guys built a
system that was totally async and handled outages (I know they are
rare, but they do happen). I also know that async is more complex to
explain in the documentation, but it would be a more valuable lesson
for everyone working with this.

Finally, it seems odd that there is a callback which gets data as well
as a response from credit_card.create() with data. Since it uses a
callback, shouldn't the credit_card.create() method return nothing and
everything just get sent to the callback? Does .create() somehow block
until it gets a response?

best,

jon

--
jon stevens
founder
415-878-6678

Voost: A better way to manage athletic events - https://www.voo.st/

[Andrew LeBlanc]

Hi Jon,

We decided to have apps explicitly set stage vs prod in their JS because we anticipated that many apps would forget to change the domain on the JS src and would end up confused why their calls aren't working (because they are going to the wrong endpoint). 

Feel free to make the tokenization.v2.js file load async if you like. I may make the sample JS in the tokenization tutorial use async, the current code is just a quick example of what a call looks like. What kind of outage handling are you looking for? Any real outage handling would require code hosted on your end.

The current setup for tokenization.v2.js is that the WePay.credit_card.create() function will return an error if the parameters you pass are completely incorrect (ie missing require parameters, etc). Otherwise, we attempt to make the API call and will return the results from the API call in the callback function. I agree it's probably simpler to just always return everything in the callback regardless of whether we made the call or not, so I will make this change.

Let me know if you have any other thoughts or questions!

Andrew

[Jon Stevens]

The explicit endpoint setting seems like an odd tax for everyone to
pay for handling stupidity. It isn't required in the backend api, so
why require it here?

I just went through a big outage with Mixpanel and learned a lot of
(hard) lessons about interacting with third party api's using JS. It
is hacky (like 99.99% of all the JS out there), but basically, what
you need to do is setup a setTimeout() which gets called after X
seconds to check to see if the rest of the .js has loaded yet and then
call the callback with an error message indicating that the JS failed
to load in time.

Instead of a simple <script src=""> like you have now, this would
require a small block of minimized JS that you hand out to people
which would attempt to async load your .js file and then do the
setTimeout dance. The general idea being that you *always* want that
callback to get called so that I can just build my app around
success/error messages and not have to worry about the networking
layer. Obviously, I can do this on my end, but I think that if you go
this extra little mile for your customers, they'd appreciate it in the
long run. Given the amount of downtime of your competitors .js file,
I'm surprised they don't handle this better as part of their
documentation. (cough https://status.stripe.com/ cough).

Thanks for clarifying the response stuff.... I agree, putting it all
in the callback is a better system.

Some documentation explaining all the various errors we can receive
would be nice. It helps when designing a Payment Tag and accounting
for spacing. ;-)

I noticed that your .js file in production isn't minimized. I really
appreciate it being unminimized on stage as it helps with debugging,
but I really think prod should be minimized.

best,

jon

[steve blackwood]

Aleksey,

has anyone decided to write the application for oscommerce or zencart yet???

seems that the guru's of programming could do it fairly easily, with
the api for php now completed.

please advise.

[Aleksey Sanin]

Steve,

Yes! There are WePay plugins for both ZenCart and osCommerce:

http://www.zen-cart.com/downloads.php?do=file&id=1387
http://www.alanpinnt.com/wepay-oscommerce-plugin/

Best,

Aleksey

--
Aleksey Sanin