I am trying to understand how the https://squareup.com/ square Credit Card reader works.
What would be the underlying middleware that is being used to
send the data to the squareup server,
process the payment
send verification to a user of a successfull payment
This is implmented on the iPhone, could there be a generic middleware that could be used for other devices to access this service created, so we could have all type of smartphones access a similar service language independent?
Also what security protocols would be used to ensure the data is sent encrypted over the network?
Their own website contains details about their security technology. They appear to use common and trusted technologies like SSL, which isn't a surprise.
If you want to build an application that integrates with their service, you should contact them. It's possible that they will require you to purchase a license in order to do so. They would also be the authority on the protocols and middleware required to integrate with it.
Related
I've read the Binance API documentation but it's still not clear to me whether it allows for a 3rd party app to initiate a payment, and then just have the user confirm it.
For example, I want to build an application which would allow the user to send tokens to a previously defined address, but most of my user base won't have MetaMask or a hardware wallet (so it's not that straightforward like with using ethers.js or web3.js), they'll mostly keep their tokens on an exchange.
Also, if this can't be done through Binance, is there another exchnge that would enable this?
You can use the withdraw endpoint.
Docs: https://binance-docs.github.io/apidocs/spot/en/#withdraw-user_data
Stripe, using its stripe.js library, will exchange customer credit card information in a payment form for a token using javascript, entirely on the client. Our server never sees the credit card, only the token. As a result, we can avoid PCI compliance issues on our servers and still do direct credit card transactions.
Does PayPal offer any product that similarly allows me to directly charge customer cards, without incurring PCI compliance requirements on my servers?
Note: I see that PayPal offers a vault API to exchange credit card numbers for tokens. However, this API itself requires an OAuth bearer token that must be kept as a server secret, not to be shared with browser clients. Therefore, the CC# must travel to our servers for the vault API call to be issued, and therefore incurs PCI compliance requirements on those servers. I wonder, is it perhaps possible to generate an OAuth token that only has permissions to write new credit cards into the vault? I could then give this limited-scope bearer token to a javascript client library, and call it from the client, effectively replicating what stripe.js does.
(Context for the question: we need to accept PayPal due to customer demand, but also want to accept credit cards directly. I either need to use Stripe and write my payment processing code twice for two separate integrations, or I need to find a solution via PayPal that doesn't involve PCI compliance, as that is a headache I definitely want to avoid.)
The process described above is called client side tokenization. PayPal does support tokens, but not for credit card data and thus you can't capture credit card info on your own page without PCI. Seems kinda odd that PayPal is one of the few major credit card processors that doesn't support it.
We currently use the API for embedded signing in our web application. When reviewing doc reference guide for offline signing, I'd say it's less than crystal clear how that really works. If I'm offline when I obviously can't call the API, so how does one in fact "sign" with DS?
I can appreciate how our client app (again, which currently does embedded signing) can prepare an envelope 'request' offline, and then send that request once we have connectivity. However the REST API guide says the user in fact "signs" the doc while offline -- how does the user ever get to the Docusign interface to do signing?
from the docs
To use Offline Signing, the customer using a client application to
create an envelope on an Internet-capable device, such as a smart
phone or tablet, that is not connected to the Internet and has a
recipient fill out and sign (or initial) the envelope documents. When
the device later connects to the Internet, the client application
uploads the envelope information to DocuSign where it is processed.
Does our offline app (running, say, in/as a Chrome app) somehow connect to local client Docusign software onboard the laptop or mobile device while offline? Any pointers to more complete documentation?
From the docs:
"IMPORTANT: Access to the offline signing capability is limited by
integrator key information. If your integrator key does not have the
correct authorization, you cannot use offline signing. Access to the
offline signing capability will be evaluated on a case-by-case basis."
The reason is because your software would be responsible for providing the legal evidence that the transaction actually happened with the proper security checks. This requires a tighter business arrangement and agreement between your company and DocuSign.
Please get in touch with your business development manager and they can set up a time to talk.
-mb
Some time ago, it was commonplace for smartphone apps to open a browser to a registration page with a CAPTCHA, or to require separate signup via web, because API signup was seen as vulnerable.
Now most apps seem to offer registration via native form, though endpoints for this are usually not documented in their public API. I haven't seen many reports of this being abused to create spam accounts.
How is this done? Is there a standard crypto/handshake process to verify real signups, or does signup typically rely on undocumented endpoints and simple API key passing?
Embedding yields a better experience but has the issue you mention. Yes, the service owners on the other end are still worried about this and combating the problem. And undocumented APIs don't help and the service owners know this.
One of the tools in the toolbox these days is keys assigned to devices which can be used for throttling. This would essentially let you limit the amt of service that can be consumed on a per device basis and it would require you have a device (or can steal the key from one) in order to provide service. So long as the process to issue keys to new devices is strong (a solvable problem) then you can offer a CAPTCHA-free signup experience within the confines of what you are willing to give to a device.
I'd also note that there are other well known approaches you can use, like IP throttling and handshakes with other service providers (like a phone carrier). Depending upon the problem domain these are on the table too...
I'm building an app that needs to accept credit card payments with something like active merchant. In terms of security, is it possible for it to live on heroku and use authorize.net (or similar) as the payment gateway?
What if it needs to store the credit card numbers?
Edit
Would not be forwarding users to authorize.net.
The simple answer is yes, I believe so, but beyond that it depends.
You can set environment variables for various keys and other values related to the third party service(http://docs.heroku.com/config-vars), or just check them in and deploy them.
If you are using the hosted payment service for authorize.net, and forward to their site, you don't need ssl yourself. If you will be hosting the form where credit card number and personal info are submitted, then forwarding this to authorize.net via their API on the server, you need to set-up ssl for heroku (http://docs.heroku.com/ssl) so that your form is secure.
Now, it is one thing to accept payment via credit cards and just pass it thourgh, it is another to save credit card numbers and other private information. Without pointing you to various security standards docs (i.e. PCI DSS applies here), I will simply say that unless you absolutely have to, don't store CC numbers and related personal information, just forward to the gateway and make sure you aren't logging those fields (http://guides.rubyonrails.org/security.html#logging). If you do need to store credit card data, I think you need to have more control of the database and server to reach compliance, and I don't know a general cloud host like AWS or heroku that you can use and do this (maybe some other SO user will correct me). Using a payment gateway like authorize.net, however, can get you there.
I'll also point out that different states now have laws about storing sensitive data (like MA, where I live), so yet another reason to avoid doing it unless it is essential to your business model.
For a somewhat dated, but good general discussion of PCI compliance, look here: http://broadcast.oreilly.com/2009/02/pci-in-the-cloud.html