Integrate Stripe with Unity

Good day,
Need help

I'm trying to install the Stripe API Library through NuGet Manager in Visual Studio but it installs it inside packages folder of the Project i.e before Project's Assets folder, doing this I cannot use the library

Code (CSharp):

1. using UnityEngine;
2. using Stripe; // doesn't recognise this

Then I:

1. Moved those installed files from packages to Assets folder
2. Uninstalled Stripe from NuGet (as I could now access them in my script by using Stripe;

These are the main errors that I'm getting

• PrecompiledAssemblyException: Multiple precompiled assemblies with the same name Newtonsoft.Json.dll included for the current platform. Only one assembly with the same name is allowed per platform. Assembly path: {0}
  
  
• Assembly 'Assets/Temp/lib/netstandard2.0/Stripe.net.dll' will not be loaded due to errors:
  Unable to resolve reference 'System.Collections.Immutable'. Is the assembly missing or incompatible with the current platform?
  
  
• Assembly 'Assets/Temp/lib/netstandard1.2/Stripe.net.dll' will not be loaded due to errors:
  Unable to resolve reference 'System.Collections.Immutable'. Is the assembly missing or incompatible with the current platform?

 

Only taking a guess, the first error seems to simply state you have multiple copies of the Newtonsoft.Json dll. This I believe comes with json.net as well. Just make sure you only have one copy.

The other two seem to suggest you need to get the System.collections.immutable assembly.
https://docs.microsoft.com/en-us/dotnet/api/system.collections.immutable?view=netcore-2.2

Based on microsofts docs, it appears to be added through nuget.

 

So I don't necessarily have assistance for your direct problem.

But instead I have a suggestion for overarching design.

...

Using Stripe in your game implies that you have a marketplace of some sort where people will be purchasing items. It also implies that you have a stripe account whose API key will have to be included in the code that processes charges.

On the client machine is seldom where you want that sort of transaction to occur. It creates a security hole that the client can exploit.

Usually if you have a marketplace you're going to want a server somewhere that holds all users and the purchases they've made so they can't fake purchases. This server will also be a place you control all security to and the only code that 'should' run there is your code (as long as you've secured it correctly). This is a better location to be holding your transaction keys for stripe.

Then you'd have some web interface that the client communicates with. Sending a message including client details (account session token for example) and what they want to purchase. And then the server performs all the billing transaction stuff and spits back a response.

Mind you that if your transaction/api key is in your game code, that means it's on the client machine, and that means they can gank your key. And there's a lot of bad they can do with that key if they have a bone to grind with you (for example they can flood your account with thousands of fake charges... maxing out your transaction limit which depending your account costs money, as well as sends a red flag on your account due to false charges).

...

ALSO

By doing it this way on the server, if you ever decide to change billing processors, or add, you can do that all server side with minimal to no change on the client side.

You could even pre-empt the client code to support future processors by having a "ListProcessors" method on your web service. This way the client just gets a list of processors and displays them on screen and the client clicks the one they like. The entire UX is processor agnostic allowing you to add/remove processors on the server on a whim.

Where as the counter is say you stop supporting Stripe and you go full paypal (or something else, whatever, this is hypothetical). You have to roll out an update for this to reach all clients. But what if I, lordofduct, avoid updating my game because I'm a finicky butthead. I then try to perform a transaction against stripe, but your account is closed. Have you written your code to deal with that? Have you tested for this scenario? What's your work around? Are you going to have a web call that validates I'm on the latest version of the game before transacting? If so... then you already have a server, why is that logic on the server and the billing logic not?

...

Now sure, you could do everything client side.

And some people do. I'm willing to bet stripe has a 'public-api-key' for this setup (I don't know for sure, I haven't integrated with stripe before).

But just because a ton of people do it, doesn't mean it's the best option. I personally would still shy away from it, and I'm suggesting you to as well. That is all, a suggestion.

I just feel things like finance as "critical" code, and I personally feel a design where "critical" code is centralized rather than distributed to clients will tend to be safer. It also means you can layer on security on top of the existing security of the API you're using.

 

Good points for the OP to consider (and I don't know what their actually stripe usage plan is), but to comment on this one, we use in a few of our games a force update system that once we want the user to update, the app/game doesn't even launch and keeps prompting you. We have two setups for this. Using Unity Remote for a initial boot up check and then our backend has a secondary check, just in case.

 

I'll repeat:

I could also follow that with my idealistic "dead games" rant about how this means your game is now fully dependent on a server rather than slightly dependent. You effectively have an "always online" game.

I mean this is completely subjective on my part... but I share the opinions of many gamers out there that online components of the game shouild be silo'd from offline components. I understand that the storefront may go down at some point because the store is online and must be maintained. But if I own the game, I should be able to at the very least play my offline stuff for as long as I own the game. Regardless of if the publisher/creator goes out of business.

 

Yes, but since user data is stored online anyways to avoid cheating, there is no offline gameplay. All levels are assetbundles where we can add more. There is no offline game here. It's just a free mobile game. If we go out of business, the game goes down with us!

 

If so... then you already have a server, why is that logic on the server and the billing logic not?

 

My comment was only about making sure users updated. I was not commenting about anything else, since I have no idea what the OP's plan is with Stripe.

To Edit: Any time dealing with real money especially, the more secure option is always best, which usually is through a server vs a client, so I agree with you there.

 

But my comment already covered checking for updates.

I essentially said:

Either you don't check for updates.
Or you do check for updates.
In which case why isn't your billing logic ALSO on the remote location where you check for updates?

And you follow it with:
Well you could check if you need an update and not start the game.

And so I repeated my conclusion.

 

Thank you so much for all the help and I'll make sure to keep the security checkpoints in my mind while developing it. Honestly Its my first time working with this kind of project, so maybe my knowledge is very less than you guys. The replies are so detailed and very true to keep in mind. One last question is there an easier approach to all this. Maybe something like paypal in unity. I just need a way to let the users earn some money from a game. Like for 1000 coins they can withdraw 1$ to to paypal, stripe etc etc ... Please show me a direction

 

Just so I'm understanding you correctly... you're saying players can withdraw ingame currency for real world currency?

Where is this money coming from?

I'm assuming it's coming from your account (business, whatever)... in which case... YES, PUT ALL OF THIS ON A SERVER.

Put the tracking of how many in game coins they have on a server, put all the details on the server. If you have this client side someone can easily just go in and adjust their coin value (that's stored at some location in memory, all I gotta do is adjust that value on my machine) and steal ALL your money.

...

Really, I won't even go further than that in describing all of this. Rather instead I will suggest you consult with experts (not people claiming to be experts in a forum).

When it comes to in game marketplaces that have real world currency transfer-rates applied to it. You're asking for an exploitable marketplace. There are TONS of caveats you need to cover in it that require expert level knowledge to cover all security issues. I'd even want the eyes of someone with economics knowledge because fluctuations in your market could tilt the marketplace way out of your favor and bankrupt you.

There are possibly even legal issues here as well... for example the marketplace could potentially be used as a money laundering system, or potentially be considered a black market exchange. I personally don't know all the legal ramifications here, and it all depends on your local government as well... but yeah, a lawyer would also be something I'd talk to as well before implementing such a system.

 

I support Unity IAP, and Apple and Google both provide client side purchase API's. Many of our developers use client side purchasing. The security and transactions are handled by the respective stores. IAP allows users to buy virtual goods with real money. Stripe is also a good system, and would be good to get it working on Unity, or find out if it is possible.

 

Please consider it, please!

 

We have no plans to support hard good purchases with Unity IAP.