We're building a multi-tenant SAAS web-application. Our tenants want the option to accept credit card payments for the various products that we allow them to market through our application. To support this we will require that the tenant has their own Braintree account. The tenant provides us with their Braintree API keys through our app. We then use those API keys to interact with their Braintree account on their behalf (card storage, card verification and basic transactions).
This model is the same as the model used by the existing Braintree customers WooThemes, Goodsie, TutorTrove and many more.
We need to record the tenant's API info (merchant ID, public API key and private API key) for this all to work.
My questions are:
Can we simply store this information in our application database?
Does storing this information affect the PCI/DSS scope of us or our tenants?
If we can't store the information in raw form, what is an appropriate storage form?
Note: we have contacted Braintree directly with this same question, but we didn't think it would hurt to get other opinions as well :).
Cheers,
Sam
IMHO, Please note that you will be [if not, should be] having tenant based crypt keys [each tenant can configure their own crytographic algorithm and the keys => SAAS Cusomization], Please do encrypt the AuthorizationId using the tenant specific keys and then persist in the database. These kind of sensitive data should be secured and you should have a note stating that you are maintaining these keys in the database so that the tenant's can opt out if not required and manually enter the key whenever required. This will ensure safety. By the way is your application using SSL.
Please do share your thoughts on this suggestion
So Braintree responded to this question with:
So long as your system is PCI compliant, and your merchants are aware
that their API keys are stored on your server, then you should be
fine. How you store the integration API keys is completely up to you,
and [we] don’t really have any best practices to offer.
So, it doesn't seem like this case affects the PCI/DSS scope of our product, and it seems we are free to choose an appropriate way to store the private API keys that we obtain (saravanan's suggestion is one possible option).
Related
I'm implementing solution, using OpenIdDict library for authorization/authentication, for merchant stores. Now creating OpenIdDict application for every merchant, also every merchant might have multiple selling points(Android terminals). From admin side, I would like to provide functionality to administrate selling points, and at the point merchant creates new selling point, I would like to show them OpenIdDict client id, client secret, and uniquely generated selling point id in form of QR code, to have possibility of assigning new Android terminal to specific merchant. At this point came to problem, that I can't unhash OpenIdDict client secret. Also, it's not the case where I can share client secret with merchant in advance, as the Android application would be distributed through store.
Came to this thread https://github.com/openiddict/openiddict-core/issues/452, but I find implementing custom encryption/decryption logic a bit unsafe, it might contain security issues and should be supported later.
Would appreciate any suggestions, how to do it correctly, or how it's done in other systems.
We are working on a system which retrieves data from customers' Shopify shops and provides some services based on this data. In order to make it as convenient as possible for an end-user we would like to update this data on a daily\weekly\monthly basis.
For now we only came up with a solution of implementing unlisted app, prompt a user to provide all necessary permissions for the app to access their shops and fetch the data. But the token we get doesn't seem to be valid for a long time and we probably won't be able to reuse it a day later.
We appreciate it if you can share any success cases of implementing this kind of approach.
You provide an App to the merchant they can install using oAuth. When the merchant is prompted to approve the App, Shopify will then provide your App with a long-lived access token you can use as much as you want, for as long as you want. I use a custom App from my Partner App dashboard to create these kinds of one-off Apps. It is superior to the one where the merchant has to tick off scopes and permissions IMO.
There are two kinds of token you can ask for and receive. One is considered for offline access, or long-lived. It works for everything. It is for webhooks as an example, or other access where no person is involved. But, there is also, online access tokens! Say a person clicks into the App from Shopify to do some work. You can request an online token for them to do their thing, and that token is only good for say 24 hours.
So you have options!
I am trying to make a plan to update my client's shopify stores by building Shopify app or using external library. Basically, I want to provide my clients with some convenience by automating the inventory update, order process and extra stuff.
For now, I have only two scenarios.
Whenever my wholesale inventory changes, i want to update my client's shopify product list to be updated (quantity, price and product description) accordingly.
Whenever my client(shopify store owner) receives an order from his/her customer, i want the order information to be automatically transferred to my server.
If possible, I want my clients to be able to integrate with my application without any tech knowledge. I have looked into the Shopify app (public/private) and some external API(java), because I am a java developer.
I checked Shopify Java library which requires api key and password to be able to access shopify owner's store for product/order access, but I am not sure how user-friendly this approach is in terms of Shopify owner's side.
For Shopify public app, I am not familiar with it, so I am not sure how much I can do with it.
Could somebody provide some details about pros/cons about these approaches?
Thanks.
All you need to know is that with Shopify, you can connect to their shop using standard HTTPS. Even better, it's all GraphQL now. As for credentials, Shopify is fully modern and offers you two methods of getting credentials.
Your merchant client can create credentials with permissions right inside their Shopify Admin -> Apps. They give you the keys, you're in business
You get them (or you) to simply click install your App running at some HTTPS address, and you use oAuth to get the credentials.
Either way, makes no difference to the actual code you write to interact with their shop and deal with inventory, sales etc. You do not need to make your App public in the sense of App store, so you can use your partner dashboard to create an App and oAuth install, or like I said, use the private App way.
I'm new to Xero API's and I'm trying to understand a thing.
In my Company we currently have various different “organisations” within Xero, and this number will be growing in the near future.
We also have a 3rd party web application we use for technical and management data – to which we now would like to add financial data, mostly in the form of exported Xero reports.
We had been looking at the API functionality – however as I understand it Xero is unable to grant a subset of permissions to API calls – i.e. anyone with API access would have the same level of access a standard user – so aside from being able to pull the reports we require, they would also have access to all other data, such as transactional data, account numbers, creation and deletion of invoices etc. etc. Please can you confirm whether this would be the case?
In short terms: we need to restrict the API calls to the reports only, is this possible?
If not, does Xero have a functionality where reports can be automatically exported to an external location – such as a cloud service or an FTP site or similar?
Many thanks in advance
You're correct. Once you connect an app to the API it has access to all the accounting endpoints. Payroll endpoints are the only ones that require additional scopes.
And no, unfortunately there's no way to schedule report exports either. Sorry!
I am using the standard paypal developer API (NVP) to get current inventory levels:
https://api-3t.paypal.com/nvp?METHOD=BMGetInventory&VERSION=95.0&USER=____&PWD=____&SIGNATURE=____&HOSTEDBUTTONID=_____
But, I have a concern... If the api is enabled and the key is compromised somehow, what is the worst case scenario? For example: it looks like it is possible to send payments using the API. Is there a second tier of verification of payments that happens outside the API?
I have spent around 30 minutes researching the topic without any clarity in terms of what kind of financial damage could be done if an api information is compromised.
If your PayPal API credentials are compromised then someone can make API calls on your behalf. This includes sending and/or withdrawing money from your account.
There are some ways to limit the permissions of a PayPal API credential on the pages where you set the credential up, so you might be able to create a key that is somewhat less dangerous. It has changed over time so I can't offer details; google and/or log in to your account and look.
And yes, PayPal has lots of fraud detection that it runs internally on payments, but they have no legal responsibility to figure out that your API has has been stolen and I would strongly recommend not relying on them to save your bacon in such a case.
Protect your keys, especially ones with access to your money.