does api validate balanced payment
social security number
address
account number
legal name
EIN
Date of birth
if yes, then how??
There are a two separate validation processes, one that occurs on the Customer resource and then on the Funding Instrument.
1) Customer
For customer identity verification: https://docs.balancedpayments.com/1.1/overview/resources/#customer-identity-verification
The customer identity verification is run through a 3rd party identification service each time the customer resource information is saved or updated, and is pertinent to underwriting merchants that are being paid out to.
2) Funding Instrument
For address verification: https://docs.balancedpayments.com/1.1/overview/resources/#address-verification-service-avs
Furthermore the Name, CVV, Postal_code, and Country Code fields are critical to reducing both fraud and declinations. These fields are checked by the banks, but do not result in hard failures. More info can be found here: https://docs.balancedpayments.com/1.1/overview/best-practices/#reducing-declined-transactions
Please note that even if a customer object has name or address data this is not passed on to the card object when associated.
Related
Is it possible to do authorization / access control in FHIR store?
Let me show one example:
The insurance company receive clinical information from 3 different partners, but the company need to create a different role for each one.
So, the first partner can GET any patients and POST only encounter resource.
Second partner can GET several patients and POST encounters and conditions resources.
Third partner can GET some patients and PUT some elements in conditions resource
Each partner would be responsible for authenticating the insurance company. This might be through mutual TLS certificate verification, OAuth or some other means. Once the insurance company has authenticated, the clinical system would determine what 'authorization' the company had. Every data source has full control over determining what a given requester has authorization to receive. Ideally, the server will expose a distinct CapabilityStatement to the requester after they've authenticated that reflects what they are allowed to do. Any requests that are not permitted will result in an appropriate error or will result in the data returned being appropriately filtered. The determination of what sort of filtering happens is managed by internal business rules and is not defined by FHIR, though in some cases, FHIR resources such as Contract or Consent may include terms that will influence the filtering.
I'm in the early stages of integrating Square payments. It makes sense in my application to allow users to save their card details, as we expect multiple small transactions. Square calls this feature 'cards on file'.
As part of this process you create a customer and a related card in Square's system; IDs for these will be held in my system and associated with my users; that way when they come to pay again they can select the option of using a card on file. The API to actually charge the card simply takes these two IDs and an amount.
What worries me is that my database is holding all the data necessary to charge a customer's card; I could write a script which just charges all of my customers an amount of money - naturally a hacker with access to my data could do the same thing.
I wasn't expecting to have this level of risk in my system - my assumption was that Square would have isolated me from this (via some sort of user challenge for missing data - e.g. the CCV number). It seems the safe option is to not use the 'card on file' feature and have the user re-enter every time.
Is this right, or have I completely misunderstood something here?
In order to charge a card, your Square access token is required along with the card ID. It's best practice to store that access token as an environment variable in order to limit the security risk. If someone gains access to the card IDs in your database, they won't be able to charge any of the cards without that access token that's associated with your developer account.
I did miss something - as any charge made on a customer's saved card is credited to my account (as configured in the Square portal), the only beneficiary of any fraudulent charge would be be me. A hacker could not get access to funds and therefore the risk is limited in scope.
Obviously if I was a fraudulent company there would be a risk to users - it seems the EU isn't happy with this and changes coming this year will require additional information to be captured from the user at the point of sale.
Strong Customer Authentication
I'm trying to create a recurring payment on Square, ala Stripe subscriptions. However, I am having trouble retrieving a customer's card information (specifically customer_card_id) to pass into Charge.
Our flow is such:
A customer visits to our store and subscribes to a membership, which we process via the point of sale app.
We continuously poll Square to retrieve payment information, and create membership records appropriately.
When the user's membership period expires, charge them for the next month's membership.
When researching RetrieveCustomer, I find that there is a cards property under Customer, but iterating through all the Customers under our account, they all have cards = None despite us having taken card payments via the point of sale app.
Also, looking at ListTransactions, there doesn't seem to be anything that might be customer_card_id. The IDs I see there are tender ID, location ID, and transaction ID. The card_fingerprint also looks promising but that doesn't seem right either, since a card can have both an ID and a fingerprint.
Am I missing something? Where might I find customer_card_id?
EDIT
Looks like I was dumb and my local instance of our application was just out of date with transactions from Square. After updating my data with customers we've processed since the last time I updated, customers with a non-None card property now show up. tristansokol's answer below is still valid however.
How do you process the first charge? You need to explicitly add the card on file, it won't be added by default from processing a transaction from a customer. See: https://squareup.com/help/us/en/article/5770-use-card-on-file-with-the-square-point-of-sale-app
I have an app that uses Parse as its backend, and has Stripe integration. On Parse, I store a Stripe customer id on my User class, and I have a custom class that has a charge token associated with it, so that a customer can create a service request, and when a provider accepts and fulfills that request, they can have the charge be sent to their recipient id.
A user could cancel the service request, or a provider could show up to the user's property and find that the property is unserviceable for various reasons. In this event, we have a cancellation fee that the users are charged.
I want to make sure that if the cancellation fee is charged, it gets charged to the same card that the user used to request the service. I noticed that when I fetch all of the cards from a customer id, they always show up in the same order, but when I add a card, it doesn't always add it to the end of the array that gets returned when I fetch cards. So, if I just stored the index of the card, a user could add a new card, and it would possibly take the place of the one that was being charged for the service. If I charged a card based on the index for a cancellation, it could charge the incorrect card. Would it be PCI compliant to store the cardID used to create the charge token on the Parse object that contains information about the service, so when I call my functions to create cancellation charges, I'm charging the same card?
Thanks for anyone who can provide some information on this.
The only sensitive data that you want to avoid handling is your customers' credit card number and CVC; other than that, you're welcome to store any other information on your local machines.
As a good rule, you can store anything returned by our API. In particular, you would not have any issues storing the last four digits of your customer's card number or the expiration date for easy reference.
from: https://support.stripe.com/questions/what-information-can-i-safely-store-about-my-users-payment-information
In the example response for the List Payments endpoint in the Square Connect API Documentation, it shows 'Description' as a returned key, but the data I am receiving from Square does not show that key.
I have verified that the payments do have a Description attached to them (by downloading the transaction report from the Square Dashboard).
Thanks for identifying this inconsistency between the documentation and the API. The Payment object does not in fact have a description field.
However, the following fields included in a Payment object do contain merchant-specified notes about a payment (assuming the merchant provided them at the time of sale):
The payment_note field of a Payment’s tender contains a merchant-specified note about the form of tender used for the payment. This is generally present only for Tender objects with a type of OTHER.
The notes field of a PaymentItemization in a Payment contains a merchant-specified note about that particular item in the payment. Note that PaymentItemizations are only available from the Retrieve Payment endpoint (not List Payments).
The Description column of the transaction report provided by the merchant dashboard is simply a comma-separated list of the names of the items included in the payment, along with any notes for each item. The Connect API does not provide this list directly, but you can recreate it for a payment with the fields of the payment’s itemizations.