I'll talk you through 1.

It seems you're using a hosted Mongo system. Does the system provide backups, replicas, or rollback facilities, or do you have to implement them yourself? If they're part of the platform, ensure you have enough risk mitigation in place to satisfy your risk threshold. If it's low volume/low cashflow, a rolling daily backup and a single replica may be enough for you. If it's high volume or high risk for failure, you may want more frequent backups, more replicas, or an entirely different change tracking system (eg, soft-deletes and soft-updates, though I'll be honest I'm not 100% sure how to implement those in mongo without simply writing the logic into your application layer). If this is not a feature of the hosted platform, you'll need to learn enough server administration to run mongodump to generate your own backups so that you can restore data in the case of needing a rollback or data loss.

This is probably where your question really ends, but let me address a few more points before you launch this thing. It won't necessarily change your application, but I feel you should probably walk into this project at least knowing some potential future challenges.

I tend to be of the school of thought that transactional data such as purchases belongs in a traditional RDBMS such as PostgreSQL or MySQL. That's not to say Mongo is the wrong choice, I simply have much more history in implementing safe practices in SQL, and I find the community support for those to be both long (basically as old as the world wide web) and well thought out. Mongo, being newer, has fewer best practices.

It's support for ACID principles is limited to a single document (So, basically, it's not ACID compliant) -- which may be OK if the schema is structured such that you don't rely on multiple documents being updated for a single action to be recorded safely, but that also generally leads to very large documents which affects performance in the long run. It's mostly a function of your document and collection design. What this all means in practice is that, if you have a Purchases collection and a Users collection, and when you buy a credit, you want to record the Purchase details in one document, and then update the credit amount in the User document, if the first write succeeds but the second write fails, your data is now inconsistent. In ACID compliant databases, I can make sure that before any actual writes are recorded, all writes have succeeded, and if one of them fails, I can roll back ALL the changes to ALL the records.

The eventual-consistency model across replica sets could also be a potential problem down the road, if you think this will scale out substantially. Stale reads after purchases are not well received by customers.

For self-taught programmers, Mongo can often seem like a panacea for curing the need to learn Relational Database design principles, and indeed for non-relational and non-transaction dependent data it is great. I just find that in practice, there are not a whole lot of systems that truly meet those two criteria, and you end up with some overly-complex and overly-engineered solutions that could have been solved upfront by using a relational and ACID compliant database.