Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cell-based architecture for resilient payment systems

americanexpress.io

Post reply on HN
Print view View original

51–60 of 66 posts

Re: Cell-based architecture for resilient payment systems

#51

Post by inigyou »

whazor wrote: post #49
physix wrote: post #9

Nobody uses Amex for payments, so the system isn't ever under high load. Just kidding! I find the idea quite good, and have to assume that the amount of payment fails they experience due to partitions/outages isn't very high and that the post-payment reconciliation and reclamation process gives them the liberty to rank availability a bit higher than correctness. One thing that looked a bit shaky was the interplay bet…

Amex is gaining popularity for acceptance

Do they still charge ridiculously high fees to merchants?

Re: Cell-based architecture for resilient payment systems

#52

Post by inigyou »

Scaled wrote: post #50
badlibrarian wrote: post #10

Ah yes, the financial services company that runs a travel agency, allows me to book my hotel and rental car weeks in advance, registers a hold for incidentals for both the hotel and car when I check in, then blocks the card when I try to buy dinner that night in that same hotel due to fraud detection. Last week it required me to take pictures of my face from multiple angles to regain membership privileges. I suspect…

I would have nope'd out so hard if they asked for face pictures.

That's just normal for banks now

Re: Cell-based architecture for resilient payment systems

#53

Post by greengreengrass »

inigyou wrote: post #31
physix wrote: post #30

Earlier quoted context omitted.

That would be the good case. But what if the cell doesn't know that, and it's holding, for example, a stale account number?

Generally with a credit card, or many banking systems more generally, because they predate computers, it's possible that a charge might be accepted even if there's no knowledge whether the money is in the account. As long as the person who was supposed to have paid is identifiable, the money is taken from their account anyway in the end, and if they don't have it, they get sued and their wages garnished, and if they…

Too true. We all think these payment systems are 'strongly consistent' and RDBMS vendors and projects since time immemorial love to talk about their ACID suitability for payments. In reality, zoom out enough and it's all eventually consistent and resolved through the legal system if the computers failed.

Re: Cell-based architecture for resilient payment systems

#55

Post by zipy124 »

Insimwytim wrote: post #25

Whole lot of nothing. This isn't about payment technologies, it's not about isolating transactions, it's about scaling the middle layer. What's worse it's not even explained what middle layer does. No info on how routing works, no info on data synchronization. Folks just learning Kubernetes and write extremely abstract stuff.

The problem is there is no incentive to talk about things in simple terms, in both companies and academia. If you make your work look simpler, it is assumed it is easier and thus your contribution is less. There are incentives therefore to make your work look more complex than it is.

Re: Cell-based architecture for resilient payment systems

#56

Post by badlibrarian »

Scaled wrote: post #50
badlibrarian wrote: post #10

Ah yes, the financial services company that runs a travel agency, allows me to book my hotel and rental car weeks in advance, registers a hold for incidentals for both the hotel and car when I check in, then blocks the card when I try to buy dinner that night in that same hotel due to fraud detection. Last week it required me to take pictures of my face from multiple angles to regain membership privileges. I suspect…

I would have nope'd out so hard if they asked for face pictures.

PayPal does it. Synchrony Bank does it. Use your eBay credit card to buy toner, shipped to the address on your card, just like you do every 90 days? Must be fraud.

They email you an alert. You click "this is okay." Card still doesn't work, you call. Rep asks ID questions, still not enough. Says he has to text a QR code linking to some wonky app that videos your face, no other option.

You can't even login to pay the card off and cancel without going through the process.

Re: Cell-based architecture for resilient payment systems

#58

Post by tempest_ »

inigyou wrote: post #51
whazor wrote: post #49

Earlier quoted context omitted.

Amex is gaining popularity for acceptance

Do they still charge ridiculously high fees to merchants?

Merchants near me are using more computer based terminal that seem to take nearly every thing. Amex's cut probably smaller compared to squares or stripes.

When talking to a local merchant about why they dont take amex the fee was not mentioned. The merchant said that visa and mastercard settle at the end of the day and they get their money but amex it was sometimes 4 or 5 days before they actually got their payment.

Re: Cell-based architecture for resilient payment systems

#59

Post by chmod775 »

As described, if one "cell" crashes, you re-route/retry everything on the other cell. Assuming your system is deterministic and the inputs stay the same, the second cell should now break as well.

This reads to me like an attempt to patch a system that's already fucked beyond belief while pretending you're doing "engineering".

Fancy implementation of a retry loop attempting to minimize downtime.

Post reply on HN