Hacker Newsnew | past | comments | ask | show | jobs | submit | pjan's commentslogin

Banks starting to charge more for (crossborder) transfer, Visa/MC charge more for tokenized card payments, which they mandate adoption of, and most likely more of this.


> Ideally, you'll support at least two providers you can switch between, if you can afford the development of supporting two

It is however not that simple if you want to remember your customers payment information, and don’t want any PCI-DSS liability or obligations. You’ll need a card vaulting solution in the middle, which comes as additional burden (and cost!) on top of the other payment provider integration. There’s big volumes you need to process to offset all of this, and probably not ROI sensible for many.


Do you have any suggestion for "card vaulting providers"? This is interesting actually, store cards without PCI-DSS obligations and use those cards with the payment provider that makes the most sense at that point in time.


Spreedly, TokenEx, Very Good Security are some that I'm aware of.

I'm surprised Stripe hasn't come with their own multi-processing router solution for enterprises at this point; whichever major payment processor who would do this, could become a de facto choice as primary or secondary payment gateway for enterprises requiring this.


hyperswitch[1] looks to be trying to work in this space.

1. https://github.com/juspay/hyperswitch


Nice! Didn't know this. There are commercial solutions which offer even more integrations https://www.ppro.com


Even with a card vaulting solution I think it may be difficult to support more than one provider, at least for Visa and MasterCard, due to Visa's Stored Credentials Framework (SCF). SCF was a set of requirements for using stored cards that Visa originally announced would be required starting sometime around 2017, and MasterCard said they would adopt it too.

So many payment processors were going to fail to meet the deadline to implement it they moved it back a year. The main payment processor we use met that deadline and we started using it. But many others did not and it was pushed back another year. I'm not sure when it finally actually came into effect because I didn’t pay much attention after that.

Under SCF when you charge a card and intend to store that card you have to set a flag in the transaction signaling that intent. After the transaction you need to save the Visa or MasterCard assigned transaction ID.

Later, when you use the stored card there's flag you have to set that marks this transaction as using a stored card, a flag you have to set if the charge is merchant initiated (e.g., an automatic subscription renewal) rather than customer initiated (e.g., they order something from website and elect to put it on their on file card), and you have to provide the transaction ID of the transaction that was done when you first stored the card.

It's that prior transaction ID that is the problem. With many payment processors the transaction ID they give you is one they generate, not the one that Visa or MasterCard generates.

As part of implementing SCF those processors will remember the Visa or MasterCard transaction associated with transactions that had the "we are going to store this card" flag set, and so later when you use the stored card you just have to provide the transaction ID they gave you and they look up the Visa/MasterCard transaction ID to send to the card company.

So say you charge a new Visa card through provider X, setting the "we are going to store this card" flag. X gives you an X transaction number X-1234, which you remember, and X remembers that X-1234 means Visa transaction ID V918273.

A year later it is time to auto-renew that customer, and you want to do that through provider Y. But Y's interface expects a Y transaction ID. You can't give them X-1234 and have them do anything sensible with it.

As far as I can tell for many combinations of X and Y there is simply no way to do an on file charge at Y with a card that was put on file after an X transaction, except perhaps by at the time of the X transaction also doing something like a $1 authorize with Y and hoping that the Y transaction ID for that will work with Y for later doing an actual charge.

You need some way to get the Visa/MasterCard transaction ID, and you need X and Y to allow you to provide a Visa/MasterCard transaction ID for the SCF stuff.


As far as I understand, you can payout in USD on a EEA domiciled account, and you won’t be incurring any fees.

It’s the crossborder settlement which they charge for, which I don’t think is crazy, as it just reflects the underlying costs Stripe must be incurring themselves.

As someone who ran a business in multiple countries, the bank always charged similar fees for these transfers between accounts. Stripe letting me settle directly in the account where I want the money to land, rather than me having to log in to my bank and initiating a transfer manually where fees are ~the same is definitely a better option, which I’m happy they offer.


1% is enormous for this. I think the cost of a SWIFT transfer is maybe $3 to them, regardless of amount. If you're doing $100k/month of USD sales and payout once a week, it is a huge markup.

They are clearly losing money on their (really expensive) forex fees so are trying to recoup this by this payment.

There is no intrinsic reason I see why the fees are so high for this.

Edit to add: they actually use ACH for US bank USD payouts, so even less cost than SWIFT.


Again, in my understanding is Stripe not forcing you to—-as a EEA business——settle USD in a US domiciled account; you can settle the USD in an EEA domiciled account and not incur the cost. If you then want to repatriate the money to the US with your bank, you can do so yourself.

I also just looked it up how much this costs with my bank, and it's a minimum fee of $25 + agent/intermediary bank fees on top of it, for amounts less than $5,0000.

I assume that Stripe can negotiate better rates though, but for the sake of simple pricing, and cost-averaging over different amounts (which are, given that they serve the long tail, likely heavy weighted on smaller amounts), it is not inconceivable that this 1% is closer to cost than one might imagine.


Banks do not charge a percentage of the transfer for wires or ACH. It is a set fee, usually in the range of $15-35 (stripe probably pays less than a dollar). That is a huge difference between charging 1% of the transaction.


This was previously not possible but looks like they have allowed it now. That is the reason why I had a US USD account in the first place, for Stripe USD payouts. They did not allow USD payouts to any European accounts last time I checked a few years ago, only to US accounts.

The 1% is for all non local currency payouts. Example: "The primary currency for Stripe accounts in France is EUR. All other currencies fall under alternative currencies." "1% Of the payout amount, when you choose to payout in select alternative currencies." Ref https://stripe.com/docs/payouts/alternative-currencies So basically this will result in very expensive payouts for anyone doing USD charges outside US or EUR charges outside Europe. Like many SaaS companies are. Charging any other currency is problematic for many customers so it is not really an option. Like I don't want to be charged in pesos for a SaaS that I am using.

The alternative is to have Stripe convert USD to my local currency. For a small 2% fee.


Paidy | Platform Engineer & Data Engineer | Tokyo, Japan | ONSITE | VISA

We’re hiring Scala Engineers to scale, support and contribute to the continued building of our financial services, including our core product – Paidy. Paidy is Japan’s largest cardless online payment service, handling thousands of transactions per day for famous local and international brands.

We use Scala of the functional kind to solve the unique challenges of operating a complete payments stack, where we are the issuer, acquirer and payment gateway. As a member of the Paidy engineering team you will be thoughtful and deliberate about tackling bottlenecks, developing new features and improving existing systems. You’ll have the opportunity to develop a deep understanding of functional programming, distributed systems, data stream processing and machine learning. You’ll also be positioned to teach or mentor others.

We're an international team based in the heart of Tokyo, and will soon be one of the biggest Scala teams in all of Japan. We sponsor & manage the visa process.

Stack: Scala, typelevel libraries, some low-level akka, cassandra, elastic, docker, ...

The job descriptions we're hiring for are the following:

- Platform Engineer: https://www.linkedin.com/jobs/view/466697084/

- Data Engineer: https://www.linkedin.com/jobs/view/466817215/

and we have multiple openings for each of them, with a focus that may vary based on your experience and interests. For the current batch of hires, we focus on people with relevant previous experience.

Usual interview process:

1) CV check and 30 minute video call about your past, passion & interest in Paidy

2) Take home challenge, followed by a review interview

3) Final interview with one of the founders

Interested, or have more questions? pjan+hn@paidy.com


No, it is not!

I share my time over Singapore and Japan, and no one ever touches your stuff in both places; not during a bathroom break, not even during a lunch break when people leave their shiny macbooks to keep their seats warm.

This immediately invalidates all the other comments saying that uniformity of behaviour/lack of entrepreneurship is a consequence of this in Japan, since it also works in Singapore where (perceived) entrepreneurship is much higher.

Theft is a problem. It doesn't bring about good things, nor does the lack of it bring about bad things.

Quite the opposite!


There is indeed no theft in a dictatorship.


> This immediately invalidates all the other comments saying that uniformity of behaviour/lack of entrepreneurship is a consequence of this in Japan, since it also works in Singapore where (perceived) entrepreneurship is much higher.

No, it doesn't. In Japan, that safety is a product of a culture of uniformity, which invariably results in a lack of entrepreneurship/innovation.

In Singapore, that "safety" is the product of an authoritarian government that severely curtails civil liberties and human rights. Free speech and political freedoms are restricted, chewing gum is banned for non-medical purposes, and the punishment for possessing 500+ grams of pot is a mandatory death sentence. Archaic and barbaric punishments such as caning continue to be practiced. Such an oppressive government is not something we want in the West, regardless of the "benefits."

As Benjamin Franklin said:

> They who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety.


Yep, Japan has no innovation and no entrepreneurship :rolleyes:

I guess all those famous Japanese brands just some how happened without any entrepreneurship and their products happened without any innovation.

Sorry, I didn't mean for this to be snarky but seriously... Your excuses are BS and don't live up to any scrutiny. It's not an either/or thing.


> I guess all those famous Japanese brands just some how happened without any entrepreneurship and their products happened without any innovation.

The Japanese are very skilled at taking what others have done and incrementally improving it. By reverse engineering American cars, they were able to beat the Americans at their own game, producing more reliable, efficient, and defect-free cars. Thanks to the cooperative nature of their society, they avoided the antagonistic relationship between the UAW and the Big 3 American automakers that led to many of the financial problems faced by the Big 3. Similar success was seen in electronics by companies like Sony, allowing them to produce high quality TVs and other high-tech consumer products.

This sort of societal cohesiveness (along with cozy government-industry relations) removed a lot of barriers to the sorts of large and capital-intensive undertakings that are common in manufacturing. But it rarely produces the sorts of game-changing innovations that Silicon Valley, and America in general, is known for. The nature of Japanese society also prevented companies from restructuring and outsourcing their manufacturing to China, which allowed South Korean (and increasingly Chinese) rivals to largely displace them in consumer electronics. There's a reason why Sony's products are so unpopular these days - they're expensive as hell. Even in the automotive industry, Toyota/Honda are starting to get overtaken by the likes of Hyundai and Kia.

> Sorry, I didn't mean for this to be snarky but seriously... Your excuses are BS and don't live up to any scrutiny. It's not an either/or thing.

Actually, the problem is that you have a very shallow understanding of the situation. This isn't the sort of thing you can really comprehend with some weekend blog-reading. The Japanese should be credited for exploiting their post-WW2 alliance with the US to rapidly transform their economy while much of the world dicked around with communism and most of the West was in no better shape than Japan itself after the destruction of WW2. But transient effects stemming from quirks of history, although intriguing, don't disprove the bigger theory.


Except my old mailman who grew up in San Francisco in the late 40s told me that nobody in his multistory apartment building when he was a kid ever locked their doors even if they went out of town. I'm not sure what the difference is but it's not authoritarianism.


In Belgium you get paid to do a PhD. For engineers it is competitive to market rates, for all other majors it's even much higher than what they receive in the private sector (but harder to get into/less possibilities.

This also applies for non-citizens.


Also: Japan authorities looking into closure of Mt. Gox bitcoin exchange

http://www.reuters.com/article/2014/02/26/bitcoin-mtgox-japa...


I do believe Mark Karpelès' LinkedIn Summary is due for an update:

"... I have a long experience in company creation, and experienced almost any imaginable kind of trouble. Now is the time to create something that will be solid enough to handle any situation, anytime."


For those interested: page 8 unredacted... http://imgur.com/aU5mCVP


Based in Japan here.

First, I don't think the author claims that the risk is the same; quite the opposite IMO. He clearly states that getting a high exit is very difficult here, that sales cycles are longer, ... which, all the same, make for a higher risk. It's however the task of the entrepreneur to take this into account and be successful within this frame.

Having said that, it is an undeniable fact that, in general, Japanese are culturally more risk-averse. Case in point are for example the low seed rounds that can be raised amongst the Japanese investors (i.e. VC not being an entrepreneurial endeavour), the popularity of the idea of life-long employment, ...

"lack of disruptive ideas" actually does ring with me, at least when it comes to web-based companies. "Unique ideas", no doubt about that. But disruptive ideas as 1) having a major impact, 2) being viable, and 3) not a localised clone of a successful foreign company... I do challenge you to name me some.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: