matthewarkin

You could take a look at combining ACH and Stripe Connect.

a lot of time spent in Stripe's IRC chat room, recommendations from Stripe support to users

You can, just not everyone has access or the ability to write server-side code. For instance if you used Wix, Squarespace, some generic website builder you often have no access to the underlying server-side code.

the ssl itself was only $10/year, the $20/month heroku charges you to use a custom ssl cert.

yeah, but I wanted SSL for the complete trip, free SSL would terminate at Cloudflare leaving the connection from Cloudflare to Heroku not-protected (which would be questionable from a PCI perspective). And then for some reason, I couldn't get the connection from Cloudflare to Heroku to work under the *.herokuapp.com ssl cert.

Their SSL endpoint, I plan on just moving to an ec2 instance

Commencepayments.com, costs me $40 a month to run (though if I wasn't lazy I could drop it significantly - $20 for heroku + ssl and $20 for cloudflare) launched last February and just hit the $1000 mark!

I can say that my last few tickets have been faster than normal, definitely not 3 hours though. And currently I have an issue open since Friday

I estimated 1 minute to roughly include research and reproduction time. The week estimation was then based on a 40 work week

Yeah, to my recollection I can't recall a single person joining the irc room with a python code base, I can't really say why or why not, but it should be noted that it is popularity in terms of support, not in terms of api requests.

The naive interpretation would be that people using stripe with a python codebase in general need less technical support with the integration.

Failures caused by this should have returned an api_error, a card_error (like card declined) would have been returned upstream from Stripe.

Woot, a postmortem from Stripe! I've been asking for these for over a year and hopefully we'll see more from them in the future.

Location: San Francisco, CA Remote: Yes Willing to relocate: Yes Technologies: Node.js, Elasticsearch, Couchdb, Java, Mongodb, Swift Résumé/CV: https://mattarkin.com/wp-content/uploads/2015/10/Arkin-Matth... Email: mharkin at stanford dot edu

Notes: I'll be graduating in June with a B.S. in Science, Technology, and Society from Stanford (basically a mix of CS and Communication). Looking for a new-grad (though I've worked in industry since I started college) position for once I graduate.

Its pretty common for Stripe Connect integrations to charge an application fee. With Relay, Stripe would allow some apps that use connect to "move" their products database from their own database to Stripe. Also it allows merchants to sell on more platforms. It just becomes "You can use Relay and Stripe to sell on our platform, however we'll take a 1% transaction fee"

It depends on the country, Canadian Stripe accounts support USD denominated Canadian bank accounts.

You only need a US bank account to open a US Stripe account, other countries don't require a US bank account

Pricing for Windows 10 has been announced, $110 for Home and $199 for Pro. You have 1 year to upgrade for free, then you have a license for Windows 10 forever for that machine and you'll be supported for the lifetime of that device (as defined by Microsoft). If you don't upgrade within that year then you'd have to pay for the upgrade.

I've learned quite a bit from IRC (mostly in #stripe). Though the learning has been way more indirect since I spend most of my time helping others. So people would ask "how do I do X?" and the learning comes from researching ways to do that and evaluating the pros and cons of each. The second way that I've just learned is by getting exposure to how a ton of people have integrated certain aspects.

Stack overflow is great for solving individual bugs (which definitely works in some IRC rooms), while IRC is more of a "how to do something" or "why should I do it this way" type of environment

The issue with AVS is that it only matches numbers (so 123 Main Street and 123 Maple Street could both return true). The other issue is apartment numbers. If the address on file is 123 Main Street #123 but the customer puts #123 on line 2 in your form is that a match or not?

They do have a user ticketing system (Uservoice), there is just no user facing view of it.

When you send an email to support@stripe.com (or any of the public email addresses they put on blog posts), it goes to Uservoice. Then it gets triaged, depending on the severity of the ticket, if it falls into account or developer related support it gets assigned into a queue (at times it gets put in the wrong queue and then has to get reassigned). But long story short there is a system.

Phone support is also being worked on were told.

That said I do love Stripe but I do agree that support needs to be fixed, though I may have a bias as I see a much higher percentage of upset users than most.

This selling point also causes many of the issues Microsoft and Windows is known for. With choice comes compatibility issues with often leads to crashes and blue screens.

Apple can ensure the latest version of their OS and Apps work on all their supported machines and hardware configurations. This sort of testing and assurance is nearly impossible for Microsoft

At least in the Valley, hours tend to be flexible, at my current position, people walk in between 8 and 11. My team's stand up is at 11 so the rule is be in the office before them, but even then sending an email saying that traffic was bad, or Bart is dumb, or you're waiting for Fedex is okay (the assumption being you'll join the standup remotely and get some work from from home).

With the large companies that have shuttle's the flexibility is because they need to stagger all their busses.

It really depends on the culture and the type of environment though, much more "corporate" positions and cultures would require better on-timeliness, but being told to take the day off for being 6 minutes late seems odd for a developer position.

Given the recent PCI Discussion.

As opposed to Stripe.js where the credit card inputs in a custom designed form live on the merchant's DOM, Braintree just set it up so that it replaces each field with an iframe (that also allows for custom styling), so that the credit card info gets entered directly to Braintree despite it looking like your own page.

Awesome Braintree!

I think more awesome, was the hosted fields you just launched, so that I can have a custom, stylized form where each credit card input is its own iframe.

https://www.braintreepayments.com/features/hosted-fields

Last I checked this was also only offered for credit cards, not their debit cards :(

Historically, the thought has been that the iframe and a redirect could both be treated as SAQ A (the easiest form of compliance), was because if you changed the iframe that was displayed or the page the customer was linked to it would be extremely difficult to steal customer information in a silent way.

So if a merchant links to paypal.com/merchant, and I inject js to change it to paypal.com/matthewarkin. The merchant would immediately know something was wrong because they are no longer receiving money. The issue with how Stripe, Braintree, and others have implemented their javascript and iframe implementations is that is pretty easy to replace the iframe with a malicious url (paypal.com/matthewarkin) but still allow the merchant to receive their funds.

A simple fix for this would be the api keys used to instantiate the iframe only be usable from the iframe and could not be used to call the create token api directly.

The new Stripe.js does not render an iframe, the credit card information is still entered on your site so $("#credit-card-number").val() would return the card number. The transmission of the card data happens through the iframe. So the card number gets copied to the iframe, and the iframe makes the post to Stripe.

Stripe got their QSA to renew them but Visa hasn't updated their site was what I was told.

Their Attestation of Compliance: https://www.dropbox.com/s/xpk1n72n0gtd5o5/Stripe_AOC_2015.pd...

Thats basically the concept, once you have malicious js you can replace the iframe with a malicious one that looks the same. You can even have it still create a legitimate card token, so in theory the website would never know they are hacked. The other PCI SAQ A scenario is linking off site. So while malicious JS could change the link you redirect to customers to it would be noticed because the customer may see a sketchy url and the merchant would see a decrease in sales.

I'm actually working on a blog post about this, basically the argument is whether or not you use Stripe.js and the invisible iframe and Stripe Checkout is that as soon as you have some malicious JS in your DOM all bets are off, and while stealing credit card info from Stripe Checkout may be harder than just doing $("#credit-card-number").value, its not /that/ much harder.

(As part of my blog post, I actually use some malicious js on the merchant site to steal card info from a Braintree iframe (the drop in))