I often build payment integrations in my applications. When I receive responses from PayPal or square I am usually able to record a bunch of data from the payment partner. Some of that data I could use to maintain a local copy of the transaction which occurred on the payment facilitator's service.
Often I record the data which I feel supports the needs of the application in question. But I am interested in what is considered standard practice for this data management?
Your question about "standard practice" is fairly broad, but it is safe to store object IDs and other non-card data returned from the Stripe API.
https://stripe.com/docs/security#out-of-scope-card-data
Other data protection/privacy laws may apply to your business.
(From a previous answer on a similar topic: https://stackoverflow.com/a/41577523/12474862 )
Related
My fullstack React eCommerce application interacts with Stripe using my Express backend.
I need the client to be able to perform CRUD operations on products and orders, and as such they are currently stored in my mongoDB database.
However, I have discovered that interacting with Stripe's API is significantly easier if products (and thus orders) are stored on their database too.
As such, I am considering using both databases as sources of truth. However, this means that every CUD operation on one would need to be reflected in the other, making things more complex.
What is the best approach to this predicament? Thank you!
It really depends on your use-case and how you'd like to structure your integration. You're correct that it would make it easier to integrate with Stripe's API if you have the products and other information stored on Stripe. Stripe does provide a way for you to listen for any changes made to an object and update your own database accordingly using Webhooks [1].
You can build a webhook endpoint and listen to a variety of events in order to receive updates in real-time. This would allow you to maintain your own database without worrying about writing a script that polls API to retrieve the latest state of data/objects.
[1] https://stripe.com/docs/webhooks
I use two independent eCommerce platforms that don't officially support communication with one another, however, both have exposed REST API for managing products, orders, etc.
My question is: how can I leverage their APIs to allow the two platforms to exchange data?
Neither platform offers a workspace to code API calls and execute on retrieved records, so I don't understand how this scenario fits in the client server model.
Would this require a third node to be set up to act as the client with each of the eCommerce platforms acting as servers?
If so, then I surmise that this client would need to, for example, perform a GET request from Platform A, store the retrieved records in a database, then perform a POST to create the records in Platform B.
If my above understanding is correct, can anyone please advise on a platform/service with which this functionality can be built and managed? Is Postman what I'm looking for?
I'm still new to web API development, so please excuse my ignorance.
Any help would be much appreciated.
Thanks
I'm setting up a blockchain database using bigchaindb for an ecommerce platform. Although, it's more like a secure backup. My application already runs on a SQL database. The blockchain database saves data in the form of assets and transactions in mongodb. The bigchaindb also provides all it's data via a public API. Later, I also want to query this database.
I tried searching for it, but didn't get a dedicated discussion on database design for e-commerce on blockchain. If you know any such article out there, let me know, it'll be helpful.
As per my personal assertions:
Every information like, the user_profile, order, products, reviews etc can be saved in the form of assets. Moreover, operations like transferring product from the seller to the customer can be saved as transactions. Also, a customer creates a review as an asset, while putting the review on the product will be a transaction.
Of course, I will need to create Key-Pairs as identities for individual users, but I think I shouldn't save it in the blockchain, as it's data is accessible by the public API. So, I can save it in the actual SQL database of the application.
Do you think it's the best way? Any suggestions from your side?
I am not sure you can have a "schema" in a / any blockchain. For your purpose, which I believe is little strange https://github.com/ssbc/ssb-db should be enough.
For example I have 2 databases. One of them is called ecommerce which contains real customer information. Another is called ec1 which basically contains only views from tables of ecommerce.
We use our ec1 database to connect to our website or apps. How secure is this method in terms of back end security?
Only exposing ec1 is better than exposing ecommerce because you can reset ec1 using your "safe" values in case of corruption and you can keep some secret data only stored in ecommerce if it doesn't need to be used by your website or your app.
However, this is only a small portion of backend security. Having two different databases with real data and data views doesn't matter a lot if someone can access your server OR can corrupt your data.
I mean, if someone found a way to get some data he should be not authorized to read, it is bad even if it comes from ec1 and not from ecommerce
So yeah, exposing only views is a BETTER solution, but nothing can be said on the overall security because it mainly doesn't depend on that
EDIT: A detailed explaination of backend security is way beyond the possibility of a simple stackoverflow answer (and probably i am not the best teacher) but for basic server security you must take care of:
- Firewall to stop every request but your webapps ones.
- Updated software
- good database passwords
- The user you use for your application queries must only be able to perform operations on ecl1 database, while the views should be generated with a cron and using a different user
These are the main security enhancement tips that comes to my mind
Business Model:
This business makes handmade specialty items from a large inventory of photo examples on the web site. The owner does not want to bill until the item is ready to ship.
I'm sure the business model itself can keep us debating for days, but please do not question his approach as that is not really the point here. It is simply how he wants to run his business.
Design:
I have developed a system for him which manages his transactions (no financial information) until he is ready, whereupon he selects the transactions by checking the ones he wants from a query-select-list of unprocessed orders. I can then convert each ordered item to an HTML stream, REST objects, or whatever. The customer should receive the invoice email and click on a button to take him to PayPal for payment.
I want to use the REST API object model to send all the required information to PayPal, describe the invoice and then send the email/invoice to the customer via the API. It is not uncommon to have multiple items ordered at once.
Q1 - The API looks like it supports this usage but can anyone experienced with its use tell me if there is a show stopper I have not discovered yet?
Q2 - I have already developed an HTML template for this purpose. Perhaps prematurely. Does REST API allow for the use of templates? I do not see how yet but hoping there is a way.
Many thanks.
2K
After some more research and a half hour with Integration Support:
A1: There are no show stoppers in the scenario described above. The REST API (and PayPal) supports the usage I have in mind. If anyone desires I will post back results in a few days after code complete and a bit of testing.
A2: I was informed that my own HTML templates are supported but I still do not see how. With the spirit of "Trust, but verify" I will continue with my efforts and ask for Integration Support at that point if I need it.
My cup and my Stack both overflow. I am fortunate.
2kTech