I am developing a platform (mobile) that connects local restaurants to people in my town, allowing them to quickly pay and pickup food, and allow restaurants to move their payments to a more streamlined, online service that costs them nothing on top of processing fees (generic 2.9% + 30c). I ask to know the following:
Does Square allow this type of platform to utilize their service?
Does Square allow businesses with merchant accounts (for accepting credit cards) to accept payments WITHOUT square accounts?
If the answer to 2 is “No”, then if businesses with merchant accounts join square, are they assigned some sort of ID or token that encompasses ALL the info needed to process payments?
If the answer to 3 is “Yes”, is this all the Merchant information needed by the Square payment processing APIs and SDKs for server side applications* other than the customer’s card which is collected using the mobile payment form in the mobile SDK**, and if not, what is the other needed payment information on the restaurant side?
My final question regards PCI compliance. I understand that Square handles PCI compliance with their POS customers, but am curious about the developer and 3rd party platform creators. Are developer customers given the same protections when storing the Merchant info (this question kind of depends on the answer for 3, regarding the supply of developer tokens) and if not, am I allowed to avoid PCI compliance if the merchant tokens and card info is only processed on my backend server and never stored? Is there a site that details the functions of a service (like the creation of the payment request) that requires PCI certification?
*Not including risk and fraud assessments which is theoretically done off the app (these are old, reputable businesses.)
**Is that the same service, or is it part of a different service that facilitates transactions between a customer and a FIXED account?
Sorry if this too long, and if these questions have already been answered, please reroute me to the respective forum posts!
No, unfortunately you must have a Square account to accept payments through Square.
Yes, each Square merchant has a merchant_id that is globally unique.
The merchant must pass IDV so we can verify they’re “real” so to speak. Until they pass this check, they will not be approved for processing card payments.
PCI compliance is handled entirely by Square, including in the third party development. If you’re planning on taking payments, the raw card data will never hit your backend servers; for example if you’re using the In-App Payments SDK to allow customers to enter their card data, we will tokenize it in the app itself (client-side) in a secure manner, and you’ll use this secure token (called a nonce) to actually use our APIs to process a payment. You’ll be able to get some basic information such as last 4, and the brand of the card, but the entire card number nor the CVV would ever be made known to your server.
Can you clarify what you mean by a fixed account?
Please let me know if you have additional questions or concerns!
Thanks for the answers!
My question was about the nonce system, as well as it’s integration with the createpayment and completepayment objects in the charge api. I was asking if the nonce system was between the customer (cardholder) and a fixed merchant account, but I now see after reading the documentation, that the nonce is just the source_id used to hold the single use card info.
My question is now:
What information does the nonce consist of (other than card numbers,Cvc,exp) ?
The nonce is pretty much just the essential card information (combination of the number, CVV, postal, and expiration date). It’s generated based on what the customer has entered, so that we can use it to attempt to charge the card. Once it’s used, you won’t see the nonce again (one time use, and expires after 24 hours), but you will see card details that I mentioned earlier (like the last 4, and brand for example) on the Payment object. Let me know if I misunderstood what you were asking, or if you have any other questions of course.