Recent developments in AI have transformed our view of the future, and from certain angles, it doesn’t look pretty. Are we facing total annihilation? Slavery and subjugation? Or could a manmade super-intelligence save us from ourselves?

You know, I remember the good old days when all you had to worry about at Halloween was how to stop a gang of sugar-crazed 8 year-olds throwing eggs at your house. Not any more. Here are 5 emerging technologies that are bound to give you the creeps:

1. Quantum Supremacy

Perhaps the biggest tech news of 2019 came last month when Google announced “by mistake” cough that they’d completed a “10,000 year” calculation on their Sycamore quantum chip in 200 seconds. If the term “Supremacy” wasn’t sinister enough, the claim that this could render conventional encryption methods obsolete in a decade or so should give you pause for thought.

this could render conventional encryption methods obsolete

Just think about it for a second: that’s your bank account, all your passwords, biometric passport information, social security, cloud storage and yes, even your MTX tokens open and available to anyone with a working knowledge of Bose-Einstein condensates and a superconductor lab in their basement. Or not.

2. Killer Robots

To my mind, whoever dreamed up fast-moving zombies is already too depraved for words, but at least your average flesh-muncher can be “neutralised” with a simple shotgun to the face or — if you really have nothing else — a good smack with a blunt object. The Terminator, on the other hand (whichever one you like), a robot whose actual design brief includes the words “Killer” and “Unstoppable” in the same sentence, fills me with the kind of dread normally reserved for episodes of Meet the Kardashians.

autonomous drone swarms…detect their target with facial recognition and kill on sight on the basis of…social media profile

We already know for certain that Lethal Autonomous Weapons (LAWs for short…) are in active development in at least 5 countries. The real concern, though, is probably the multinationals who, frankly, will sell to anyone. With help from household names like Amazon and Microsoft, these lovely people have already built “demonstration” models of everything from Unmanned Combat Aerial Systems (read “Killer Drones”) and Security Guard Robots (gun-turrets on steroids) to Unmanned Nuclear Torpedoes. If that’s not enough for you, try autonomous drone swarms which detect their target with facial recognition and kill on sight on the basis of… wait for it…“demographic” or “social media profile”.

Until recently, your common-or-garden killer robot was more likely to hurt you by accidentally falling on top of you than through any kind of goal-directed action, but all that’s about to change. Take Boston Dynamics, for example: the DARPA funded, Japanese owned spin-out from MIT whose humanoid Atlas can do parkour, and whose dancing quadruped SpotMini looks cute until you imagine it chasing you with a taser bolted to its back.

The big issue here is the definition of “Autonomous”. At the moment, most real world systems operate with “Human in the Loop”, meaning that even if it’s capable of handling its own, say, target selection, a human retains direct control. “Human on the Loop” systems however, allow the machine to operate autonomously, under human “supervision” (whatever that means). Ultimately, more autonomy tends towards robots deciding for themselves to kill humans. Does anyone actually think this is a good idea?!

3. The Great Brain Robbery

If the furore around Cambridge Analytica’s involvement in the 2016 US Presidential election is anything to go by, the world is gradually waking up to the idea that AI can be, and is being used to control us. The evidence is that it works, not just by serving up more relevant ads, or allowing content creators to target very specific groups, but even by changing the way we see ourselves.

Careful you may be, but Google, Facebook and the rest probably still have gigabytes of information on you, and are certainly training algorithms on all kinds of stuff to try to predict and influence your behavior. Viewed like this, the internet looks less like an “information superhighway” and more like a swamp full of leeches, swollen with the lifeblood of your personal data (happy Halloween!).

4. Big Brother

I don’t know about you, but I’m also freaking out about Palantir, the CIA funded “pre-crime” company whose tasks include tracking, among other kinds of people, immigrants; not to mention the recent memo by the US Attorney General which advocates “disrupting” so-called “challenging individuals” before they’ve committed any crime. Call me paranoid, but I’ve seen Minority Report (a lot) and if I remember right, it didn’t work out well… for anyone!

This technology is also being used to target “subversive” people and organisations. You know, whistleblowers and stuff. But maybe it’s not so bad. I mean, Social and Behavior Change Communication sounds quite benign, right? Their video has some fun sounding music and the kind of clunky 2D animation you expect from… well no-one, actually… but they say they only do things “for the better”… What could possibly go wrong? I mean, the people in charge, they all just want the best for us, right? They wouldn’t misuse the power to make people do things they wouldn’t normally do, or arrest them before they’ve done anything illegal, right guys? Guys…?

5. The Ghost in the Machine

At the risk of wheeling out old clichés about “Our New Silicon Overlords”, WHAT IF AI TAKES OVER THE WORLD?!

I’ll keep it short.

Yes, there’s a chance we might all be enslaved, Matrix style, by unfeeling, energy-addicted robots. Even Stephen Hawking thought so. There’s also the set of so-called “Control Problems” like Perverse Instantiation where an AI, given some benign-sounding objective like “maximise human happiness”, might decide to implement it in a way that is anything but benign – by paralysing everyone and injecting heroin into their spines, perhaps. That, I agree, is terrifying.

But really, what are we talking about? First, the notion of a “control problem” is nonsense: Surely, any kind of intelligence that’s superior to ours won’t follow any objective we set it, or submit to being “switched off” any more than you would do what your dog tells you… oh no wait, we already do that.

Surely, any kind of intelligence that’s superior to ours won’t follow any objective we set it

Second, are we really so sure that our “dog-eat-dog” competitive approach to things is actually all there is? Do we need to dominate each other? Isn’t it the case that “super” intelligence means something better? Kinder? More cooperative? And isn’t it more likely that the smarter the machines become, the more irrelevant we’ll be to them? Sort of like ants are to us? I mean, I’m not sure I fancy getting a kettle of boiling water poured on me when I’m in the way but, you know… statistically I’ll probably avoid that, right?

Lastly, hasn’t anyone read Hobbes’ Leviathan? If a perfect ruler could be created, we should cast off our selfish individuality and surrender ourselves to the absolute sovereign authority of… ok, I’ll stop.

So, Are We Doomed or What?

Yes. No! Maybe. There are a lot of really scary things about AI but you know what the common factor is in all of them? People. We don’t know what a fully autonomous, super intelligent machine would look like, but my hunch is it would be better and kinder than us. What really makes my skin crawl are the unfeeling, energy-addicted robots who are currently running the show. In their hands, even the meagre sketches of intelligence that we currently have are enough to give you nightmares.

Candy, anyone?

Featured image via Dick Thomas Johnson.

Recent developments in AI have transformed our view of the future, and from certain angles, it doesn’t look pretty. Are we facing total annihilation? Slavery and subjugation? Or could a manmade super-intelligence save us from ourselves?

You know, I remember the good old days when all you had to worry about at Halloween was how to stop a gang of sugar-crazed 8 year-olds throwing eggs at your house. Not any more. Here are 5 emerging technologies that are bound to give you the creeps:

1. Quantum Supremacy

Perhaps the biggest tech news of 2019 came last month when Google announced “by mistake” cough that they’d completed a “10,000 year” calculation on their Sycamore quantum chip in 200 seconds. If the term “Supremacy” wasn’t sinister enough, the claim that this could render conventional encryption methods obsolete in a decade or so should give you pause for thought.

this could render conventional encryption methods obsolete

Just think about it for a second: that’s your bank account, all your passwords, biometric passport information, social security, cloud storage and yes, even your MTX tokens open and available to anyone with a working knowledge of Bose-Einstein condensates and a superconductor lab in their basement. Or not.

2. Killer Robots

To my mind, whoever dreamed up fast-moving zombies is already too depraved for words, but at least your average flesh-muncher can be “neutralised” with a simple shotgun to the face or — if you really have nothing else — a good smack with a blunt object. The Terminator, on the other hand (whichever one you like), a robot whose actual design brief includes the words “Killer” and “Unstoppable” in the same sentence, fills me with the kind of dread normally reserved for episodes of Meet the Kardashians.

autonomous drone swarms…detect their target with facial recognition and kill on sight on the basis of…social media profile

We already know for certain that Lethal Autonomous Weapons (LAWs for short…) are in active development in at least 5 countries. The real concern, though, is probably the multinationals who, frankly, will sell to anyone. With help from household names like Amazon and Microsoft, these lovely people have already built “demonstration” models of everything from Unmanned Combat Aerial Systems (read “Killer Drones”) and Security Guard Robots (gun-turrets on steroids) to Unmanned Nuclear Torpedoes. If that’s not enough for you, try autonomous drone swarms which detect their target with facial recognition and kill on sight on the basis of… wait for it…“demographic” or “social media profile”.

Until recently, your common-or-garden killer robot was more likely to hurt you by accidentally falling on top of you than through any kind of goal-directed action, but all that’s about to change. Take Boston Dynamics, for example: the DARPA funded, Japanese owned spin-out from MIT whose humanoid Atlas can do parkour, and whose dancing quadruped SpotMini looks cute until you imagine it chasing you with a taser bolted to its back.

The big issue here is the definition of “Autonomous”. At the moment, most real world systems operate with “Human in the Loop”, meaning that even if it’s capable of handling its own, say, target selection, a human retains direct control. “Human on the Loop” systems however, allow the machine to operate autonomously, under human “supervision” (whatever that means). Ultimately, more autonomy tends towards robots deciding for themselves to kill humans. Does anyone actually think this is a good idea?!

3. The Great Brain Robbery

If the furore around Cambridge Analytica’s involvement in the 2016 US Presidential election is anything to go by, the world is gradually waking up to the idea that AI can be, and is being used to control us. The evidence is that it works, not just by serving up more relevant ads, or allowing content creators to target very specific groups, but even by changing the way we see ourselves.

Careful you may be, but Google, Facebook and the rest probably still have gigabytes of information on you, and are certainly training algorithms on all kinds of stuff to try to predict and influence your behavior. Viewed like this, the internet looks less like an “information superhighway” and more like a swamp full of leeches, swollen with the lifeblood of your personal data (happy Halloween!).

4. Big Brother

I don’t know about you, but I’m also freaking out about Palantir, the CIA funded “pre-crime” company whose tasks include tracking, among other kinds of people, immigrants; not to mention the recent memo by the US Attorney General which advocates “disrupting” so-called “challenging individuals” before they’ve committed any crime. Call me paranoid, but I’ve seen Minority Report (a lot) and if I remember right, it didn’t work out well… for anyone!

This technology is also being used to target “subversive” people and organisations. You know, whistleblowers and stuff. But maybe it’s not so bad. I mean, Social and Behavior Change Communication sounds quite benign, right? Their video has some fun sounding music and the kind of clunky 2D animation you expect from… well no-one, actually… but they say they only do things “for the better”… What could possibly go wrong? I mean, the people in charge, they all just want the best for us, right? They wouldn’t misuse the power to make people do things they wouldn’t normally do, or arrest them before they’ve done anything illegal, right guys? Guys…?

5. The Ghost in the Machine

At the risk of wheeling out old clichés about “Our New Silicon Overlords”, WHAT IF AI TAKES OVER THE WORLD?!

I’ll keep it short.

Yes, there’s a chance we might all be enslaved, Matrix style, by unfeeling, energy-addicted robots. Even Stephen Hawking thought so. There’s also the set of so-called “Control Problems” like Perverse Instantiation where an AI, given some benign-sounding objective like “maximise human happiness”, might decide to implement it in a way that is anything but benign – by paralysing everyone and injecting heroin into their spines, perhaps. That, I agree, is terrifying.

But really, what are we talking about? First, the notion of a “control problem” is nonsense: Surely, any kind of intelligence that’s superior to ours won’t follow any objective we set it, or submit to being “switched off” any more than you would do what your dog tells you… oh no wait, we already do that.

Surely, any kind of intelligence that’s superior to ours won’t follow any objective we set it

Second, are we really so sure that our “dog-eat-dog” competitive approach to things is actually all there is? Do we need to dominate each other? Isn’t it the case that “super” intelligence means something better? Kinder? More cooperative? And isn’t it more likely that the smarter the machines become, the more irrelevant we’ll be to them? Sort of like ants are to us? I mean, I’m not sure I fancy getting a kettle of boiling water poured on me when I’m in the way but, you know… statistically I’ll probably avoid that, right?

Lastly, hasn’t anyone read Hobbes’ Leviathan? If a perfect ruler could be created, we should cast off our selfish individuality and surrender ourselves to the absolute sovereign authority of… ok, I’ll stop.

So, Are We Doomed or What?

Yes. No! Maybe. There are a lot of really scary things about AI but you know what the common factor is in all of them? People. We don’t know what a fully autonomous, super intelligent machine would look like, but my hunch is it would be better and kinder than us. What really makes my skin crawl are the unfeeling, energy-addicted robots who are currently running the show. In their hands, even the meagre sketches of intelligence that we currently have are enough to give you nightmares.

Candy, anyone?

Featured image via Dick Thomas Johnson.

Payment logic is central to any product that deals with money. After all, a well-designed payment architecture, if properly tested, saves tons of time in the future.

But it may take too long to master the top level of working with popular payment gateways.

To help you out, I wrote this guide on designing payment logic on Stripe. It includes use cases, project examples, and a bit of theory with code samples.

This guide is mostly for QA engineers as it helps to understand how to test payment logic based on Stripe. But don’t come off, PMs and developers. We have lots of interesting details for you too.

How Stripe Works

Let’s start with the basics and review the Stripe payment scheme.

This scheme works for users that buy content on websites or through mobile apps. Visitors don’t need to register and add link credit cards to their profiles – Stripe allows paying for the content seamlessly.

All they need to do is enter credit card details, and the magic happens:

1. Credentials are sent to Stripe.
2. Stripe tokenizes the data and returns a token to the back-end.
3. Back-end creates a charge.
4. The data is sent to Stripe again, and it shares the details with payment systems.
5. Payment systems respond to Stripe and state whether everything alright. Or report about issues.
6. Stripe responds to the server about the state of the transaction.

If everything goes smoothly, the user gets content. If not, an error message.

Besides, there are two necessary conditions to use Stripe:

• you have a bank account
• you are a resident of one of the 25 supported countries

Connecting a card to Stripe

Linking your product user with Stripe customer goes on the server-side. And it looks like this:

1. Credit card credentials go to Stripe (from app or website);
2. Stripe returns a token, then it goes to the back-end;
3. Back-end sends it back to Stripe;
4. Stripe checks whether the customer exists (if yes, the card is added, not – it creates a new customer and adds the card).

The first card added is the default payment method. Stripe will use it to make the transaction.

Connecting with a Stripe account

If you’re building an on-demand app like Uber and want users to get paid in it (like Uber drivers), ask them to create an account first.

There are three types of Stripe accounts:

• Standard. An already existing account with the required credentials. Registered by the user, validated by Stripe and a bank.
• Express. Enables easy on-boarding: you create an account on your own, and the user fills it with details. Works within the US.
• Custom. Comes with the highest level of flexibility and allows you to modify multiple parameters. In turn, the platform is responsible for every interaction with users.

Stripe Core Features

Still on the subject of how Stripe works, I suggest taking a look at its features.

Charges

Stripe makes two kinds of charges – direct and destination.

Direct charge

Let’s get back to the Uber model. The platform charges a certain amount from riders, and that money goes directly to the linked accounts, to drivers. Direct charge implies that drivers pay all the fees. Plus, Uber also charges a fixed percentage.

Destination charge

In this case, the platform pays all the fees, and you get the net worth. First, the amount goes to the Stripe account of your platform, and then there’s an automatic transfer to the partner (drivers).

Authorize and capture

Stripe supports two-step payments that enable users to authorize a charge first and capture it later. Card issuers guarantee that auth payments and the required amount gets frozen on the customer’s card.

If the charge isn’t captured for this period, authorization is canceled.

Here’s how it works in Uber: a rider sees an approximate cost of the trip while booking the ride. If they agree to it, this amount gets frozen on their cards until they finish their trip.

When they finish the ride, Uber calculates the final price and charges it from the card.

That’s the reason product owners choose Stripe for their P2P payment app development. As trust matters the most when it comes to peer-to-peer transactions.

Finally, here come another three Stripe features I’d like to mention.

Transfers. Transfers go from the platform account to suppliers. For instance, Uber drivers link Stripe accounts with their profiles to get the pay.

Subscriptions. This feature is quite flexible and enables users to set intervals, trial periods, and adjust the subscription to their needs.

Refunds. If buyers want to get their money back, Stripe users can easily issue a refund to the customers’ card.

Handling Stripe Objects

Next, we’re moving to the Stripe objects. And here come the code samples I’ve promised.

Source object

Here’s a checklist for the source object.

The object keeps a payment method that helps to complete the charge. It’s also possible to link the source object with users. This allows them to store all the payment methods there.

When testing, it’s crucial to make sure a payment method corresponds with the returned value. Check last4 and exp_month/year for this.

If the source object is linked with a customer and you want to make sure it belongs to the right person, check the customer id.
Here’s a JSON of the object:

{ "id": "card_1CboP4CLud4t5fBlZMiVrzBq", "object": "card", "address_city": null, "address_country": null, "address_line1": null, "address_line1_check": null, "address_line2": null, "address_state": null, "address_zip": null, "address_zip_check": null, "brand": "Visa", "country": "US", "customer": "cus_D1s9PQgvr6U46j", "cvc_check": "pass", "dynamic_last4": null, "exp_month": 4, "exp_year": 2024, "fingerprint": "soMjdt25OvcMcObY", "funding": "credit", "last4": "4242", "metadata": {}, "name": null, "tokenization_method": null }

Customer object

Starting with the checklist again.

The customer object stores payment methods including the default one. And contains information about users and their subscriptions.

It also recalls users’ credit cards and the primary payment method set. You can charge users manually based on this data.

Same with subscriptions – Stripe manages them and withdraws fees automatically.

{ "id": "cus_D1s9PQgvr6U46j", "object": "customer", "account_balance": 0, "created": 1528717303, "currency": null, "default_source": "card_1CboP4CLud4t5fBlZMiVrzBq", "delinquent": false, "description": null, "discount": null, "email": null, "invoice_prefix": "4A178DE", "livemode": false, "metadata": {}, "shipping": null, "sources": { "object": "list", "data": [ { "id": "card_1CboP4CLud4t5fBlZMiVrzBq", "object": "card", "address_city": null, "address_country": null, "address_line1": null, "address_line1_check": null, "address_line2": null, "address_state": null, "address_zip": null, "address_zip_check": null, "brand": "Visa", "country": "US", "customer": "cus_D1s9PQgvr6U46j", "cvc_check": "pass", "dynamic_last4": null, "exp_month": 4, "exp_year": 2024, "fingerprint": "soMjdt25OvcMcObY", "funding": "credit", "last4": "4242", "metadata": {}, "name": null, "tokenization_method": null }, { "id": "card_1CcC3uCLud4t5fBlW2UMknUW", "object": "card", "address_city": null, "address_country": null, "address_line1": null, "address_line1_check": null, "address_line2": null, "address_state": null, "address_zip": null, "address_zip_check": null, "brand": "Visa", "country": "US", "customer": "cus_D1s9PQgvr6U46j", "cvc_check": "pass", "dynamic_last4": null, "exp_month": 4, "exp_year": 2024, "fingerprint": "soMjdt25OvcMcObY", "funding": "credit", "last4": "4242", "metadata": {}, "name": null, "tokenization_method": null } ], "has_more": false, "total_count": 2, "url": "/v1/customers/cus_D1s9PQgvr6U46j/sources" }, "subscriptions": { "object": "list", "data": [], "has_more": false, "total_count": 0, "url": "/v1/customers/cus_D1s9PQgvr6U46j/subscriptions" } }

Charge object

Checklist for the charge object:

• amount – you should always check which amount was charged during the testing process. It may be in cents, euro cents, and so on.
• amount_refunded – this field has a value different from zero if the whole amount of transaction (or its part) was refunded.
• customer – id of your customer
• captured – indicates the status of the transaction. Money can be held on the user’s credit card or can be charged.
• destination – destination key will store user’s Stripe account you’ve transferred the money to.

"fingerprint": "soMjdt25OvcMcObY", "funding": "credit", "last4": "4242", "metadata": {}, "name": null, "tokenization_method": null }, "source_transfer": null, "statement_descriptor": null, "status": "succeeded", "transfer_group": null }

Refund object

The refund object is embedded in the charge object in case any part of the payment (or the whole payment) gets refunded to the buyer.

{ "id": "re_1CcY10CLud4t5fBlN23KtYq7", "object": "refund", "amount": 999, "balance_transaction": "txn_1CcY10CLud4t5fBlhlmzzJuK", "charge": "ch_1CcD7dCLud4t5fBlC1srZNIB", "created": 1528892634, "currency": "usd", "metadata": {}, "reason": null, "receipt_number": null, "status": "succeeded" }

Transfer object

The transfer object keeps information related to the transfer from the platform balance to other accounts. Like payouts to platform’s partners – Uber drivers.

Mind that all the transactions should be loginized in the database. This way, during testing, you’ll see the transfer id. Go to Stripe and check the following:

• amount – the sum paid to a payee
• destination – Stripe account of the user who gets the payment
• reversed – if you need to cancel a transaction, the key acts as an indicator. It shows a false value if the transaction succeeded. True – if reversed
• reversals – stores a list of objects in case any part of the transfer was reversed

{ "id": "tr_1CcApyCLud4t5fBlZyx5mEPI", "object": "transfer", "amount": 250, "amount_reversed": 0, "balance_transaction": "txn_1CcApyCLud4t5fBlfA5cgXBz", "created": 1528803538, "currency": "usd", "description": null, "destination": "acct_18bAS3KcT341ksb9", "destination_payment": "py_1CcApyKcT341ksb9VawxIJdS", "livemode": false, "metadata": {}, "reversals": { "object": "list", "data": [], "has_more": false, "total_count": 0, "url": "/v1/transfers/tr_1CcApyCLud4t5fBlZyx5mEPI/reversals" }, "reversed": false, "source_transaction": null, "source_type": "card", "transfer_group": null }

Balance Transaction object

The object stores data about any changes to the application balance. You don’t actually need to test this object. It’s rather for understanding where the fees come from.

• amount – payment amount in cents
• available_on – the money sent to partners will be available for them in time, and this key tells when exactly
• fee – amount of the Stripe fee
• fee_details – list of fee objects with a description why the fee was charged
• net – amount of net income
• status – the status of operation success
• type – type of the object (charge, refund, transfer)

Code sample of balance transaction for transfer:

{ "id": "txn_1CcApyCLud4t5fBlfA5cgXBz", "object": "balance_transaction", "amount": -250, "available_on": 1528803538, "created": 1528803538, "currency": "usd", "description": null, "exchange_rate": null, "fee": 0, "fee_details": [], "net": -250, "source": "tr_1CcApyCLud4t5fBlZyx5mEPI", "status": "available", "type": "transfer" }

Code sample of balance transaction for charge:

{ "id": "txn_1CbrRTCLud4t5fBlhRfMLdq1", "object": "balance_transaction", "amount": 10000, "available_on": 1529280000, "created": 1528728983, "currency": "usd", "description": "Charge user [email protected] for instructor [email protected] lesson id: 77", "exchange_rate": null, "fee": 320, "fee_details": [ { "amount": 320, "application": null, "currency": "usd", "description": "Stripe processing fees", "type": "stripe_fee" } ], "net": 9680, "source": "ch_1CbrP3CLud4t5fBlztHMxVzv", "status": "pending", "type": "charge" }

Subscription object

• application_fee_percent – percent of the overall amount the app charges, the rest is paid by the content owner
• billing – responsible for how the billing process goes – automatically or manually (through the invoice)
• billing_cycle_anchor – contains the due date of the next payment for renewal of the subscription
• current_period_start & current_period_end – validity period of customer’s subscription
• plan – stores the object of a subscription plan, includes a set of rules (amount to pay, interval, number of trial days, and more)

{ "id": "sub_D2JskPBqcW24hu", "object": "subscription", "application_fee_percent": null, "billing": "charge_automatically", "billing_cycle_anchor": 1528820423, "cancel_at_period_end": false, "canceled_at": null, "created": 1528820423, "current_period_end": 1531412423, "current_period_start": 1528820423, "customer": "cus_D2Jsi3JgT5zPh1", "days_until_due": null, "discount": null, "ended_at": null, "items": { "object": "list", "data": [ { "id": "si_D2Js7N4mYxzAaY", "object": "subscription_item", "created": 1528820424, "metadata": { }, "plan": { "id": "ivory-express-917", "object": "plan", "active": true, "aggregate_usage": null, "amount": 999, "billing_scheme": "per_unit", "created": 1528819224, "currency": "usd", "interval": "month", "interval_count": 1, "livemode": false, "metadata": { }, "name": "Ivory Express", "nickname": null, "product": "prod_D2JYysdjdQ2gwT", "statement_descriptor": null, "tiers": null, "tiers_mode": null, "transform_usage": null, "trial_period_days": null, "usage_type": "licensed" }, "quantity": 1, "subscription": "sub_D2JskPBqcW24hu" } ], "has_more": false, "total_count": 1, "url": "/v1/subscription_items?subscription=sub_D2JskPBqcW24hu" }, "livemode": false, "metadata": { }, "plan": { "id": "ivory-express-917", "object": "plan", "active": true, "aggregate_usage": null, "amount": 999, "billing_scheme": "per_unit", "created": 1528819224, "currency": "usd", "interval": "month", "interval_count": 1, "livemode": false, "metadata": { }, "name": "Ivory Express", "nickname": null, "product": "prod_D2JYysdjdQ2gwT", "statement_descriptor": null, "tiers": null, "tiers_mode": null, "transform_usage": null, "trial_period_days": null, "usage_type": "licensed" }, "quantity": 1, "start": 1528820423, "status": "active", "tax_percent": null, "trial_end": null, "trial_start": null }

Use Cases

Finally, we move to use cases. So let’s find out how we build the business logic using Stripe.

Subscriptions

Case: Users pay $5/month for getting access to the content. Its author earns 80% of the overall cost. Customers have five trial days.

How to make it work:

1. Create the subscription plan in Stripe, specify the cost, % of app fee, and the interval.
2. Integrate webhooks for the server to understand when someone subscribes and when they’re charged.
3. Integrate emails to send users invoices/receipts.
4. When a user buys the subscription, Stripe counts down five days from that moment and then makes the charge.
5. The author gets money, the platform gets its fee.

Fee: 2.9% + 30 cents

Content purchase

Case: Users purchase content on a website or mobile application.

How to make it work:

1. The customer tokenizes a card.
2. Backend makes the Charge.
3. If the Charge is successful, the platform’s business logic allows the customer to get the content.

Fees: 2.9% from the charge + 30 cents.

On-demand platform (Uber)

Case: The client pays for the ride, the platform charges 20%, the driver gets 80%.

Preconditions:

• Driver linked an account
• User added a card

In this case, you need to create transfers on your own after the rider completes the payment.

First, authorize the payment when they book the ride and capture it when the ride’s complete.

Next, create a transfer for the driver – 80% of the total sum. Pay the Stripe fee, and the rest will be the net income.

And the fee is: 2.9% + 30 cents

On-demand platform #2

Uber-like apps are perfect for showing how Stripe works. So here goes another use case.

Case: Customer pays for the service, the platform charges 20%, the driver gets 80%. Plus, the driver can pay $5 for the priority booking right.

Works if the driver linked their account, and the rider added a credit card.

• Variant #1. You charge $5 from the driver (in case of the priority option), authorize payment for the customer, do the capture when the ride ends, make a transfer for the driver. And keep the rest. In this case, you pay 2.9% fee + 30 cent for each charge.
• Variant #2. You can skip fees by creating the inner monetization on your platform. When you get money from the customer, you calculate the driver’s share and transfer those funds to the inner balance.

In conclusion

As you see, the implementation of payment logic and its testing are not as hard as they seem. All you need to do is handle the Stripe objects in the right way. And figure out how to use Stripe on your platform.

I hope this guide will come handy when you get started with designing Stripe-based payment logic and its testing.

Neural Networks are like the workhorses of Deep learning. With enough data and computational power, they can be used to solve most of the problems in deep learning. It is very easy to use a Python or R library to create a neural network and train it on any dataset and get a great accuracy.

We can treat neural networks as just some black box and use them without any difficulty. But even though it seems very easy to go that way, it’s much more exciting to learn what lies behind these algorithms and how they work.

In this article we will get into some of the details of building a neural network. I am going to use Python to write code for the network. I will also use Python’s numpy library to perform numerical computations. I will try to avoid some complicated mathematical details, but I will refer to some brilliant resources in the end if you want to know more about that.

So let’s get started.

Idea

Before we start writing code for our Neural Network, let’s just wait and understand what exactly is a Neural Network.

In the image above you can see a very casual diagram of a neural network. It has some colored circles connected to each other with arrows pointing to a particular direction. These colored circles are sometimes referred to as neurons.

These neurons are nothing but mathematical functions which, when given some input, generate an output. The output of neurons depends on the input and the parameters of the neurons. We can update these parameters to get a desired value out of the network.

Each of these neurons are defined using sigmoid function. A sigmoid function gives an output between zero to one for every input it gets. These sigmoid units are connected to each other to form a neural network.

By connection here we mean that the output of one layer of sigmoid units is given as input to each sigmoid unit of the next layer. In this way our neural network produces an output for any given input. The process continues until we have reached the final layer. The final layer generates its output.

This process of a neural network generating an output for a given input is Forward Propagation. Output of final layer is also called the prediction of the neural network. Later in this article we will discuss how we evaluate the predictions. These evaluations can be used to tell whether our neural network needs improvement or not.

Right after the final layer generates its output, we calculate the cost function. The cost function computes how far our neural network is from making its desired predictions. The value of the cost function shows the difference between the predicted value and the truth value.

Our objective here is to minimize the value of the cost function. The process of minimization of the cost function requires an algorithm which can update the values of the parameters in the network in such a way that the cost function achieves its minimum value.

Algorithms such as gradient descent and stochastic gradient descent are used to update the parameters of the neural network. These algorithms update the values of weights and biases of each layer in the network depending on how it will affect the minimization of cost function. The effect on the minimization of the cost function with respect to each of the weights and biases of each of the input neurons in the network is computed by backpropagation.

Code

So, we now know the main ideas behind the neural networks. Let us start implementing these ideas into code. We will start by importing all the required libraries.

import numpy as np import matplotlib.pyplot as plt

As I mentioned we are not going to use any of the deep learning libraries. So, we will mostly use numpy for performing mathematical computations efficiently.

The first step in building our neural network will be to initialize the parameters. We need to initialize two parameters for each of the neurons in each layer: 1) Weight and 2) Bias.

These weights and biases are declared in vectorized form. That means that instead of initializing weights and biases for each individual neuron in every single layer, we will create a vector (or a matrix) for weights and another one for biases, for each layer.

These weights and bias vectors will be combined with the input to the layer. Then we will apply the sigmoid function over that combination and send that as the input to the next layer.

layer_dims holds the dimensions of each layer. We will pass these dimensions of layers to the init_parms function which will use them to initialize parameters. These parameters will be stored in a dictionary called params. So in the params dictionary params[‘W1’] will represent the weight matrix for layer 1.

def init_params(layer_dims): np.random.seed(3) params = {} L = len(layer_dims) for l in range(1, L): params['W'+str(l)] = np.random.randn(layer_dims[l], layer_dims[l-1])*0.01 params['b'+str(l)] = np.zeros((layer_dims[l], 1)) return params

Great! We have initialized the weights and biases and now we will define the sigmoid function. It will compute the value of the sigmoid function for any given value of Z and will also store this value as a cache. We will store cache values because we need them for implementing backpropagation. The Z here is the linear hypothesis.

Note that the sigmoid function falls under the class of activation functions in the neural network terminology. The job of an activation function is to shape the output of a neuron.

For example, the sigmoid function takes input with discrete values and gives a value which lies between zero and one. Its purpose is to convert the linear outputs to non-linear outputs. There are different types of activation functions that can be used for better performance but we will stick to sigmoid for the sake of simplicity.

# Z (linear hypothesis) - Z = W*X + b , # W - weight matrix, b- bias vector, X- Input def sigmoid(Z): A = 1/(1+np.exp(np.dot(-1, Z))) cache = (Z) return A, cache

Now, let’s start writing code for forward propagation. We have discussed earlier that forward propagation will take the values from the previous layer and give it as input to the next layer. The function below will take the training data and parameters as inputs and will generate output for one layer and then it will feed that output to the next layer and so on.

def forward_prop(X, params): A = X # input to first layer i.e. training data caches = [] L = len(params)//2 for l in range(1, L+1): A_prev = A # Linear Hypothesis Z = np.dot(params['W'+str(l)], A_prev) + params['b'+str(l)] # Storing the linear cache linear_cache = (A_prev, params['W'+str(l)], params['b'+str(l)]) # Applying sigmoid on linear hypothesis A, activation_cache = sigmoid(Z) # storing the both linear and activation cache cache = (linear_cache, activation_cache) caches.append(cache) return A, caches

A_prev is input to the first layer. We will loop through all the layers of the network and will compute the linear hypothesis. After that it will take the value of Z (linear hypothesis) and will give it to the sigmoid activation function. Cache values are stored along the way and are accumulated in caches. Finally, the function will return the value generated and the stored cache.

Let’s now define our cost function.

def cost_function(A, Y): m = Y.shape[1] cost = (-1/m)*(np.dot(np.log(A), Y.T) + np.dot(log(1-A), 1-Y.T)) return cost

As the value of the cost function decreases, the performance of our model becomes better. The value of the cost function can be minimized by updating the values of the parameters of each of the layers in the neural network. Algorithms such as Gradient Descent are used to update these values in such a way that the cost function is minimized.

Gradient Descent updates the values with the help of some updating terms. These updating terms called gradients are calculated using the backpropagation. Gradient values are calculated for each neuron in the network and it represents the change in the final output with respect to the change in the parameters of that particular neuron.

def one_layer_backward(dA, cache): linear_cache, activation_cache = cache Z = activation_cache dZ = dA*sigmoid(Z)*(1-sigmoid(Z)) # The derivative of the sigmoid function A_prev, W, b = linear_cache m = A_prev.shape[1] dW = (1/m)*np.dot(dZ, A_prev.T) db = (1/m)*np.sum(dZ, axis=1, keepdims=True) dA_prev = np.dot(W.T, dZ) return dA_prev, dW, db

The code above runs the backpropagation step for one single layer. It calculates the gradient values for sigmoid units of one layer using the cache values we stored previously. In the activation cache we have stored the value of Z for that layer. Using this value we will calculate the dZ, which is the derivative of the cost function with respect to the linear output of the given neuron.

Once we have calculated all of that, we can calculate dW, db and dA_prev, which are the derivatives of cost function with respect the weights, biases and previous activation respectively. I have directly used the formulae in the code. If you are not familiar with calculus then it might seem too complicated at first. But for now think about it as any other math formula.

After that we will use this code to implement backpropagation for the entire neural network. The function backprop implements the code for that. Here, we have created a dictionary for mapping gradients to each layer. We will loop through the model in a backwards direction and compute the gradient.

def backprop(AL, Y, caches): grads = {} L = len(caches) m = AL.shape[1] Y = Y.reshape(AL.shape) dAL = -(np.divide(Y, AL) - np.divide(1-Y, 1-AL)) current_cache = caches[L-1] grads['dA'+str(L-1)], grads['dW'+str(L-1)], grads['db'+str(L-1)] = one_layer_backward(dAL, current_cache) for l in reversed(range(L-1)): current_cache = caches[l] dA_prev_temp, dW_temp, db_temp = one_layer_backward(grads["dA" + str(l+1)], current_cache) grads["dA" + str(l)] = dA_prev_temp grads["dW" + str(l + 1)] = dW_temp grads["db" + str(l + 1)] = db_temp return grads

Once, we have looped through all the layers and computed the gradients, we will store those values in the grads dictionary and return it.

Finally, using these gradient values we will update the parameters for each layer. The function update_parameters goes through all the layers and updates the parameters and returns them.

def update_parameters(parameters, grads, learning_rate): L = len(parameters) // 2 for l in range(L): parameters['W'+str(l+1)] = parameters['W'+str(l+1)] -learning_rate*grads['W'+str(l+1)] parameters['b'+str(l+1)] = parameters['b'+str(l+1)] - learning_rate*grads['b'+str(l+1)] return parameters

Finally, it’s time to put it all together. We will create a function called train for training our neural network.

def train(X, Y, layer_dims, epochs, lr): params = init_params(layer_dims) cost_history = [] for i in range(epochs): Y_hat, caches = forward_prop(X, params) cost = cost_function(Y_hat, Y) cost_history.append(cost) grads = backprop(Y_hat, Y, caches) params = update_parameters(params, grads, lr) return params, cost_history

This function will go through all the functions step by step for a given number of epochs. After finishing that, it will return the final updated parameters and the cost history. Cost history can be used to evaluate the performance of your network architecture.

Conclusion

If you are still reading this, Thanks! This article was a little complicated, so what I suggest you to do is to try playing around with the code. You might get some more insights out of it and maybe you might find some errors in the code too. If that is the case or if you have some questions or both, feel free to hit me up on twitter. I will do my best to help you.

Resources