My client has a business where multiple vendors can rent their clothes. Is it possible that I can hold funds with transfer_group until a renter confirms that the package is ok? In a worst-case scenario, this can take longer than 7 days.
How would can I go about with the stripe API to solve this problem.
First I need to hold the funds until the package arrives from the vendor to the client when the client confirms that everything is ok I'll take a cut in the commission and transfer it to the vendor.
What API scheme do I need to realize this?
Related
I got a request as a developer to develop a bitcoin exchange site like https://mypatricia.co/ or https://instantcoins.ng/ I am to leverage on third party API like Coinbase, blockchain, it could be anything reliable API.
Users will be able to buy and sell bitcoin. For instance USER A makes an offer. USER B is interested in USER A's offer. When USER B clicks a button, with be a switch from USER A's wallet to USER B's wallet. Before the EXCHANGE is done. USER B is prompted to make payment in local currency.
I have been looking at https://developers.coinbase.com/api/v2#introduction https://api.blockchain.com/v3 I dont know how to go about it.
Is there any other better ones to work with?
There will be some other endpoints like
Where users get list of their orders
check wallet etc
I will appreciate your contribution
This is a very broad topic, so I'm just going to tackle few key points.
Dependency on third-party blockchain data
You can get rate limited
You might be a subjet to a man-in-the-middle attack
The source might (intentionally or unintentionally) send incorrect data.
The data is usually delayed
You'll most likely need to use another tool to create deposit addresses (since the third-party tools will allow you to create only limited amount of addresses on your account).
It's very risky and unreliable to use a third-party data. It's an industry standard to run a full node for each cryptocurrency you work with and access the blockchain data from your own node instead of a third-party API.
Escrowing the offered amount
As per your example, you need to make sure that user A is actually going to transfer the BTC. Since there are no smart contracts in BTC, you need to act as an escrow.
So you need to accept the BTC from user A to their deposit address (only your site should have the private key to this address) before you even allow them to pass their order into the queue.
Order list
Since you're going to be storing the order list on your side, you need to create a separate database and CRUD endpoints to maintain the order list.
Our site currently asks customers to provide their CC data every time they put an order. Few days later we charge the card, very often with a different amount than shown during the checkout because of merging orders, changing shipment method and so on.
We'd like to migrate to Stripe, but we'd like not to change the current behaviour. Few questions arose while we read the Stripe docs:
1) Stripe.js allows to create a Source without a customer. This seems ideal for us, but the following text from Stripe docs caught our attention:
A card source must be used within a few minutes of its creation as CVC
information is only available for a short amount of time. Card sources
do not expire, but using them after a delay can result in a charge
request that is performed without CVC information. The consequences of
this can be higher decline rates and increased risk of fraud.
So we shouldn't charge the Source few days later? If so, isn't it also a problem for Sources attached to customers, because their CVCs are forgotten as well?
2) To keep things simple, we'd prefer to avoid creating customers and managing their sources in Stripe. Stripe has the concept of single-use sources, that can be charged without attaching them to customers, but the docs say that the amount is required when they are created. We don't know the exact amount at the checkout process, so could we put a bigger number as an upper limit of what we'll charge in the future and provide the exact amount during charging the source?
So you're correct, the CVC is lost anyway but this is not the point that Stripe is trying to make. When you attach the Source to a customer, Stripe will run a $0 or $1 authorization on the card with the bank to make sure it's valid. This lets them catch expired or invalid cards immediately. This also lets them send the CVC to the bank, since they have it at that point, to catch invalid CVC which is important to combat fraud.
If you were to create a Source and not charge it for a few days, that would technically work. The risk is that when you do charge it, the bank won't see the CVC and won't be able to tell you if it was correct or not, increasing the risk of fraud.
To avoid this, Stripe recommends that you save the Source on a Customer. This is just one extra API request which lets you catch invalid cards immediately. Then, days later, when you create the charge on that customer/source, the bank might still decline it (insufficient funds for example) but you would decrease the risk of charging a bad card and catch issues immediately on tokenization. It's better for you as a business but also better for the customer in case they mistyped their CVC or expiration date, etc.
I've been playing with stripe recently and while i fully understand that the token hides the clients credit card details from the server. This tutorial suggests that the server should not rely on the data-amount since it can be changed by the client
Don’t Rely on the Form’s Price
A frequent mistake stems from using form data to contain the price of
the product being purchased, possibly via a hidden input. Because a
user can easily edit this input’s value, it’s unwise to depend on it.
Always fetch the price of the product from the server-side. Never rely
on the form to tell you. A simple database query is the preferred option.
Can someone explain to be why stripe does not include the data-amount value as a parameter in the token generation? Is there not a potential for a server side code to change the agreed price and overcharge the client.
The token is a placeholder of a pending charge, it does not know how much you are going to charge yet. Once you are ready to charge the card an api request will be sent to Stripe along with the token. The concern about the amount deals with relying on POST data from a form that can be manipulated by the customer.
Its up to you to set the charge amount. For example a hotel could authorize $100 to spend the night but then at check out discover that you used the minibar and then charge $150. Or the auto calculated shipping is off so when you actually purchase the shipping its $5 less and you decide to charge $5 less than your auth.
What you should be doing is calculating the amount to charge the customer, save it via a shopping cart like function in your DB (or serverside somehow) sending the checkout form to the customer then using the previously calculated amount run the auth then the charge.
Form data can easily be changed by the end user. Just open the page and right click (in chrome) and click inspect element. You can then arbitrarily change form data. So if you were using that, the user could set the price to $.01 for your $1,000.00 product.
The propose of tokenization in the PCI world is to keep sensitive data off your servers. Otherwise you would collect the PCI data yourself then send the amount off to the processor along with the PCI data. By not ever having the sensitive data touch your systems you save a ton of money and headache in PCI compliance. See this 115 page document: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf
Hope that helps, Please comment and I'll try to help further if it doesn't.
I'm looking for programming approaches that should be required for charging payments using cron job wisely.
The website requires recurring payments to be collected using Authorize.net. To remain PCI DSS compliance credit card info is not stored locally and uses Authorize.net CIM integration where customers enter their CC info at the hosted page. Therefore, ARB subscriptions can't be used which requires CC info to be sent from the website.
As far I know there is no possibility to create subscriptions using CIM and it requires cron jobs to charge the customer when required.
I've already integrated CIM however following are my concerns when charging customers using cron job:
Prevent multiple charges so that customer is not billed for same subscription twice. (My approach: I've a table which holds payments to be collected on a daily basis and a status field [varchar: paid/unpaid]. The status will change to paid if the charge is successful).
Server break down : If the server remains down there will be no payments collected. (My approach: The cron job will run for all payments for past 3 days with unpaid status)
Security measures : Need to know what sort of security measures is required?
Any precautionary measures which I might be missing.
ARB through CIM is a work in progress. So you would have to initiate charge manually.
As for payments there are hundreds of ways to implement and thousands of ways things can go wrong. PCI DSS 3.0 has over 200 checklist items to take care. Basic tasks to note could be:
Use a proper lock mechanism to prevent race conditions
Log everything you are allowed to log
Maintain all the logs and other data on a server not accessible through web and review the read write requests on these.
Put request rate limits and raise warnings/block depending on activity
Patch all your servers OS and software, even the ones not being used or used for something else.
Close unnecessary open ports, and uninstall unnecessary software
Limit access to very few people and access through secured systems only
Follow rigorous code review and testing procedures
Check your SSL certificate here and use strong crypto algo
Check against OWASP top 10
Properly hash and salt user passwords and put limits on reset requests, shipping address changes etc
Keep an eye on updates to the softwares you are using
Monitor the logs for penetration requests and improve security as required
There are many more depending on your setup and requirement
On your side, you can have a field (which you could pass as the order number) being either subscriptionNumber.dueDate or customerNumber.dueDate (meaning if your subscriptionNumber is 123 and it's 5/24/2015, being "123.05-24-2015")
Before sending to AuthNet, make sure this field is unique. If AuthNet processes but you don't get the response, you can still have an issue.
Is there a way in Stripe to automatically send an email to a customer when their credit card is about to expire?
Great news! There shouldn't be a need to notify the customer about expiration dates (or even replacement cards). Stripe's system automatically handles these changes with Smarter saved cards:
Now, when you save a customer with Stripe, their card will continue to work even if the physical card gets replaced by the bank. Stripe works directly with card networks so that your customers can continue using your service without interruption.
This feature started in early 2015, according to the article's date of 2015-01-21.
In the sense you're looking for the answer is likely no. If you're willing to pay for it, something like Stunning can do this for you. Otherwise I think you'd need to setup something on your system to periodically cycle through your customer database and ping Stripe about the status of any credit cards they have on file to see if any are expiring soon.
As Tyler mentioned, Stripe's Card Updater has changed the game when it comes to expired cards.
However, it won't automatically catch 100% of expiring cards. At best, maybe around 70%, as some international territories and card issuers are not yet covered.
Even so, this has made pre-dunning emails (notifying customers before their card expires) obsolete in the best case, and actively harmful in the worst case...triggering "payment problem" notifications to customers who will never actually have a payment problem. These notifications can burden support teams and cause unnecessary customer involvement & confusion.
If you decide not to send pre-dunning emails (we don't), you definitely do need to send dunning emails (when payments actually do fail) which will catch actual, expired cards missed by Card Updater, as well as other kinds of failures that couldn't have been caught by Card Updater.
This Stripe dunning checklist is useful in building the optimal system on top of Stripe.
Actually, now in stripe settings, you could set up the simple reminder email before the card expiration. It's inside Settings -> Prevent failed payments
No there is no such way. Stunning as mentioned by Dhaulagiri sure is a solution but its not free.
A simple alternative is:
When taking the card info by the users for the first time, add the
field for expiry date (stripe provides validation for it too).
Keep checking the card's expiry date at regular intervals (say
monthly or at the time of charging).
If the card is about to expire (in say a month or by the time of
next charge) handle that case to notify your customer.