Square requires authorizing the location even if you need to test credit card payments with Reader SDK. That means, I need an SSN number, but I don't have an SSN since I'm a foreigner.
How can I do that?
Currently Square Reader SDK is only available in the United States, and not available in our sandbox. Therefore you do need to be based in the United States and have credit card processing enabled, even for testing (because you would be testing with your production credentials). Please refer to our docs for more information: https://docs.connect.squareup.com/payments/readersdk/overview
Related
I need to test square payments, using google pay, from a react native application (using google's test environment described here .
Google pay, however, is not available in my country.
Has anyone done this kind of testing?
If you're using the Square Payment Form, Google Pay (along with Apple Pay) both have recently been updated to allow for testing in Square sandbox mode. For more information please refer to Square's documentation.
Google Pay supports the use of pre-defined test cards. See: https://developers.google.com/pay/api/web/guides/resources/test-card-suite
You'll need to join the following Google Group: googlepay-test-mode-stub-data
Once you've joined, you should be presented with a list of test cards when you use Google Pay in TEST mode.
If you would like to return to testing with real cards (i.e. cards become available in your country), you can leave the test group.
Recently, I received a mail from Google Play Support Team:
This is a notification that the minimum content level of your application, x, with package ID y, has been changed to Medium Maturity (3) by the Google Play Team after a regular review.
REASON FOR CONTENT LEVEL CHANGE: Violation of the Google Play content rating policy.
After a regular review, we have determined that your app includes gambling themes. The content rating of your app has been changed to reflect this content.
Please be advised that additional content rating modifications by the Google Play Team may result in administrative action, up to and including removal of subsequent applications in violation.
All violations are tracked. Serious or repeated violations of any nature will result in the termination of your developer account, and investigation and possible termination of related Google accounts.
We appreciate your contributions towards ensuring an accurate content rating experience for Google Play users.
The Google Play Team
The problem with this mail is that my app is a fitness app where no currency transaction, virtual or real, takes place.
I would like to dispute the unfair content rating given to my app and the unfair threat given to me.
Could any one please help me find an appropriate forum or email where I can forward my dispute?
Thank you!
This is the link I used for a similar email :
https://support.google.com/googleplay/android-developer/answer/2992033?hl=en&ref_topic=3453554
I have not yet gotten an answer.
I'm making a utility application for a photographer. He is going to (obviously) be taking pictures, but wants to charge people at an event for a handful of digital images emailed or shared on social media. In this situation i would have to use Paypal or Square SDKs and not in app purchasing because he is going to compose the transaction and not the customer buying the pictures. Sort of like a mini POS system. He can't pay himself with another's credentials - so it would have to be a 3rd party solution. right? Is this against Apple's guidelines?
Am I over thinking this?
If the intent is to support in-person / face to face (swipe) credit card or keyed in credit card payments, check out the PayPal Here SDKs for iOS and Android which are now available on the PayPal Developer site:
https://developer.paypal.com/webapps/developer/docs/integration/mobile/pph-sdk-overview/
There is also a version for Windows 8.1+ in Beta, available upon request. You can email DL-PayPal-Here-SDK#ebay.com for help with any of these.
We are about to develop new mobile application that requires the end user to fill his payment information, which will be redirected to a third party’s portal to pay for a certain services through the application ( using Web Services )
user send billing information using web services , Is this legal for apple ?
It's OK to integrate 3rd party credit card payment systems in your app (for example PayPal, Amazon payments, etc. or your own system) as long as you do not sell services, extensions, etc. to your app. As you say you're going to sell physical goods, it is OK for Apple. Amazon app does the same thing. Btw it is even explicitly prohibited to use in-app payments to sell physical goods.
EDIT: more answer to the detailed questions in the comment
IMHO (see disclaimer):
Shipping fees of physical goods and signup fees for your physical service are NOT services or extensions - in the sense that Apple uses it, it applies only to some additional features to your application, for example a new level in a game or a new map in a mapping app
to be legally store, transmit, process credit card information, you will have to be compliant to the Payment Card Industry Data Security Standard. Here Apple has nothing to do, but both Visa and Mastercard (and maybe also other card issuers) require that you implement these practices if you wish to process credit card data of their cards
this last requirement might be tricky so I really suggest you to look for some ready solution instead of implementing your own. See also the first answer to this question: Use In App Purchase For Real Goods
DISCLAIMER: I am not a legal authority or somebody from Apple so I can give you just hints but not a legal advice - will have to ask a lawyer for an "official" answer :)
I am looking for some good technical overview of how prepaid cards work. This post provides some basic answers but I would like to learn more.
I am helping with a project where we are going to be issuing prepaid cards that end users will use to pay for services. We don’t plan on using any third party processor. We will write our own software.
Can anyone point me to some technical resources so that I can learn more about industry standards? Some of my questions are:
What are standard scheme for the account number?
Barcode: Do they play any role in the card activation? Isn’t it just a code to look up the item at the Point of Sale?
Card activation: Is there more to it than validating that the account number exists in the database and has not been validated before etc.?
Unlock the PIN: Is this the same as flagging the account has been activated?
Thank you in advance!
The account number can be anything. Just don't use a simple incrementing number, such that it's trivial to guess account numbers.
The barcode serves as a sort of UPC for the card, though it'll have both the account number, and identifying information saying "this is a card for retailer X, in the amount of $Y"
The pin prevents someone from simply scanning the barcodes in bulk and "stealing" the amounts. Without the account number AND the pin, the card cannot be activated. Generally the pin is printed on the card under a scratch-off strip, or is otherwise hidden under packaging so that it can't be read without very obvious "damage" to the card or packaging.