I have successfully charge the customer payment profile. These transactions can be viewed in the unsettled transaction. I want to ask why these not settled automatically.
Because when a user pay the value through his credit card. I want to show that the amount has been deducted and the client has received the payment. Or i have to suppose that unsettled transaction is also a successful case?
Unsettled transactions are successful transactions. Unsettled just means the transactions have not been sent to the bank for settlement which is what starts the process of capturing those funds. This is to allow you the opportunity to void those transactions if necessary.
Settlement happens nightly so those transactions will show as settled within 24 hours of being processed.
Related
I use Stripes' webhooks and want to get notified, if the customer successfully "paid the bill". I came across two webhooks, which in my opinion both could do the job:
Webhook "invoice.paid" - According to Stripe doc: Occurs whenever an invoice payment attempt succeeds or an invoice is marked as paid out-of-band.
Webhook "checkout.session.completed" - According to Stripe doc: Occurs when a Checkout Session has been successfully completed.
My questions are:
I don't understand the second part of the "invoice.paid" webhook: "invoice is marked as paid out-of-band" -> What does "out-of-band" mean? Is this to be considered a successful payment?
Regarding "checkout.session.complete" -> This can also occur, if payment fails - correct?
Which webhooks shall I consider (or are there other webhooks) to see the status "customer paid the bill successfully"?
What is more, I don't really know if disputes should be considered as successful payments or not: On one hand, I get a invoice.paid webhook, on the other hand, I get a charge.dispute.created webhook. geeezus...
I appreciate your help! Thanks.
I don't understand the second part of the "invoice.paid" webhook: "invoice is marked as paid out-of-band" -> What does "out-of-band" mean? Is this to be considered a successful payment?
This is specifically referring to marking an invoice paid out of band (ie, the customer paid you outside of Stripe and you want to mark the Stripe invoice paid without collecting a payment). This will not involve an actual payment, but does transition the invoice to status=paid so this event fires.
Regarding "checkout.session.complete" -> This can also occur, if payment fails - correct?
This event signals only that the Checkout session is complete. Depending on the mode use for Checkout, this may or may not involve a payment. If an immediate payment is expected, the session will only complete if that payment is successful. For example mode=setup or mode=subscription with a free trial will not involve an immediate payment. A subscription with trial, though, will create a $0 invoice and fire invoice.paid.
Which webhooks shall I consider (or are there other webhooks) to see
the status "customer paid the bill successfully"?
This depends on what you mean by "paid" and "bill". If you mean specifically for invoices (whether related to subscriptions or not), then invoice.paid is a good choice. You can then filter for amounts greater than $0 etc to further constrain was "paid" means.
What is more, I don't really know if disputes should be considered as
successful payments or not: On one hand, I get a invoice.paid webhook,
on the other hand, I get a charge.dispute.created webhook.
Disputes are not payments, and should be an entirely separate discussion. You can only have a dispute after a payment. Suggest starting by reading the docs on disputes.
To summarize: What are you really trying to do? These events are related and sometimes overlap, but not always. It highly depends on what you're doing.
What's going on?
When you create a checkout session it will have an id, which you'll store in your database next to the user who started the checkout session.
When you receive an invoice.paid webhook event, it does not have any link back to the checkout session! (so you'll know someone paid, but you won't know who paid!)
checkout.session.completed solves this because it contains the id of the checkout session and the stripe customer id, which allows you to link the two, so you basically have a mapping from your customer ids to stripe's customer ids.
So simply grab the customer id from the checkout.session.completed event and store it in your database next to the relevant user, that way you'll be able to tell which one of your users is paying you when you receive an invoice.paid event!
How can this be implemented?
When a checkout session is started, store the checkout session id next to the user who started the session so you can look it up later
When you see checkout.session.completed, look at the accompanying JSON and take the stripe customer number and store it in your database (e.g. a column like stripe_id in users table). To figure out which of your users it's for, use the checkout session id to look it up in your database (i.e. the data you stored in step 1)
Now that you have the stripe customer id stored in your users table, whenever you see invoice.paid, look at the accompanying JSON, take the stripe customer number, look it up in your users table to find who paid, and update the expiry date of their subscription to 1 month into the future.
That's it!
Also good to know
Both checkout.session.completed and invoice.paid events are triggered when someone new subscribes, and only invoice.paid is triggered each month thereafter (presuming the user had enough funds and didn't cancel)
You can get to the stripe customer number in both webhook events like so (this is ruby, but should be similar with js or python):
payload = request.body.read
data = JSON.parse(payload, symbolize_names: true)
data.object.customer
=> "cus_Lvyv721cJGpYB1"
One of our customers is experiencing an issue that I am trying to debug where their order is being marked as having a $0.00 SPLIT_CUSTOM entry for our custom tender. We are following the sample and making the payment amount as the full amount in the success response of our "TenderActivity", but sometimes the payment is marked as $0.00.
What could cause the split payment entry to be $0.00?
Here is an example:
This is what was happening:
A register transaction is started and the custom tender was launched (TenderActivity)
The custom tender would temporarily malfunction.
The cashier would take card from the customer and put it into the clover hardware. The custom tender would still be on the screen, but In the background the clover hardware processes the transaction and marks the order as PAID.
While step 3 was happening the custom tender would recover and mark the tender was having paid the amount.
This causes the TenderActivity to mark the payment as complete with the full amount plus tip if present.
Clover says the order has already paid because payment was taken on the hardware in step 3, marks the new payment as a SPLIT_CUSTOM and includes the tip if given. The amount paid by the custom tender is marked as 0.00.
I'm using VBA in an Access application to pass credit card applications to Authorize.net.
In the Sandbox, when I issue a request and get a response, the response looks like:
1|1|1|This transaction has been approved.|MKCE58|Y|60138643909|06731|Company name|15.00|CC|auth_capture|||||||||||||||||||||||||||P|2|||||||||||XXXX1111|Visa|||||||1UMB1CSPUW5QIHHZIATBZCO||||||||||
Which element of this response string is the value that I must capture and use when issuing a refund of this transaction?
When I attempt to refund the transaction using either the "MKCE58" or "60138643909" as the TransactionID in:
post_string = post_string & "x_trans_id=" & URLEncode(strTransID) & "&"
I get a response of:
"The referenced transaction does not meet the criteria for issuing a credit."
I found a very old post here on SO that indicates that I need to change my account mode from Live to Test, and I did that. But that has not resolved this situation.
It looks like you are using the AIM API, so the seventh value in that pipe delimited field, 60138643909, is the transaction ID which is what you will use to request a refund.
To issue a refund the following criteria must all be met:
The transaction was originally processed and successfully settled through the payment gateway (Authorize.Net).
The transaction is submitted with the valid transaction ID (x_trans_id) of an original,
successfully settled transaction.
The amount being requested for refund is less than or equal to the original settled
amount.
The sum of multiple Credit transactions submitted against the original transaction is less than or equal to the original settled amount.
At least the last four digits of the credit card number (x_card_num) used for the original, successfully settled transaction are submitted. An expiration date is not required.
The transaction is submitted within 120 days of the settlement date of the original transaction.
Authorize.net won't ever allow you to refund a transaction that was submitted the same day. Writing a test that creates a transaction and then refunds it, therefore, is tough.
I couldn't find a way to do it through the API so:
Can I ask Authorize.net to "settle" a test transaction?
Or .. What's the right way to do this?
Settlement is a batch operation that occurs once a day starting after the transaction cut-off time specified in the merchant interface. You must wait until settlement is complete. In the sandbox, there is no way for a developer to force settlement.
This has to do w/ Amazon's Flexible Payment service:
In order to try to save transactions costs I would like to aggregate all of my customers' payments & then settle them in a single pay request at the end of the day. Is this possible?
For instance, in the same day, Bob buys something for $25, Susan buys something for $30, Tim buys something for $15. Instead of sending a pay request for EACH person immediately after they buy, I want to send a SINGLE pay request at the end of the day.
The examples Amazon gives for Aggregated Payments only lists multiple payments from the SAME user, not different users.
This isn't possible, because the fees cover the processing of customers credit and debit cards, so they need to be applied to the balance of each customer.
You could still use aggregate payments to send a pay request at the end of the day for each user (in case they buy something else), but each credit card needs to be charged and you can't combine those charges.