We have an approval setup for all Sales Order. Whenever the Sales Order is in Pending Approval, the Approver has to approve the Sales Order. However, due to some reason if the Approver rejects the Sales Order, it sends out the Rejection Notification. After that the status of Sales Order changes back to Open.
Again, the user rectifies the Sales Order and status changes back to Pending Approval. The Approver rejects the Sales Order second time due to other reason.
However, this time the Rejection Notification has not been sent as it is already sent first time.
Any suggestion how I can make the changes or where I should be looking for so that it sends out the notification every time there is a Sales Order being rejected.
Found the answer,
You have to add LastModifiedField on the Summary and then in Automation Step. This will reset the notification status field and it will send the 2nd notification.
Related
In my mobile app when the user has selected some items, I would like them to be able to review their order and see a preview of their bill (the price of each item, subtotal, taxes and total). However I would not want them to pay immediately. Once they place the order, they will not be charged until the order is accepted.
Do I calculate the user's subtotal, tax and total on my server or does stripe provide an api to handle these?
I've read the docs on invoicing and checkout, and checkout seems to be the api for my situation but I'm not 100% sure.
It depends on how you define "place the order" and "order is accepted". Normally when the Stripe's Checkout Session page is displayed to your customer and they push the "Pay" button, the transaction will be executed immediately (they paid), then the customer can be redirected back to your page or app.
If you want to somehow delay the payment until a specific timing (that you want to review or execute some logic, before eventually "accept" the order), you can consider using Checkout with Setup Intent.
I have a social app where my customer is going to make single purchases (credits/tokens/likes) using a credit card (Visa, Master, Amex, Discover). When the purchase is complete, and I receive a "succeeded" in the result "status" from the Stripe result, the customer will then be given 10, 20, 50, 100, etc. tokens to their profile that can be used now for "liking" someone.
FYI - If the user has a card saved and chooses that card, that Stripe card number and customer number is used for the payment intent, otherwise I'm collecting the card details, and passing that to the "confirmpayment()".
QUESTION - Once I call Stripe "confirmpayment()" client side, and get the result back, which shows the status (succeeded, failed, incomplete, etc.) Is it possible to receive a "succeeded" status in the result and then at some later date via Stripe's webhook, receive a different status other than "succeeded"?
FYI - I've gone through almost all test card scenarios to test for this type of condition, but it doesn't seem like it will happen? It seems like the payment will either succeed or fail on the confirmpayment() call. I'm also double checking the status result on the server side by fetching the paymentIntent from Stripe. Just to make sure the user (client side) hasn't changed it in the code (JS/Typescript).
Concern - The customer finishes their purchase, the confirmpayment result shows a status of "succeeded", their "tokens" are added to their profile at that moment and then they proceed to use them to send "likes" to another user. Then later on I get the Stripe webhook back showing a different status with "failed" or "incomplete". But by this point, "tokens" will have been used and a monetary amount based on the amount of the "token" will have been moved from my Connect account where the original purchased fund will be sent to the intended receiver's connect account. If this happens I foresee it being extremely difficult to back all this out and reverse it will out a huge headache.
ALTERNATIVE WORKFLOW - I could create a "payment" entity on the server side with a pending status and wait until I receive the Stripe webhook before I add any "tokens" to the user account/profile. This will insure there is no possibility for error, but it makes the user wait until the webhook comes in before they will see a status of "success" on their payment page and won't be able to use any "tokens" from that purchase until I get the webhook. I wanted to give them a more instant experience.
Any help or advice will be much appreciated.
The result you get back after the Promise confirmCardPayment() resolves will be the same as the status you get back on the webhook event so it will never be that a succeeded PaymentIntent transitions back to requires_payment_method or requires_action, as succeeded is an end state of the lifecycle.
Keep in mind, webhook events can be out of order, so technically you could get a payment_intent.requires_action after your payment_intent.succeeded event (if they happen very quickly.
The best thing to do is to fetch the PaymentIntent from the API (after an event) to get the "true" state of the PaymentIntent.
I would like to handle a scenario in Stripe where a trial has ended and no credit card has been entered. Currently in Stripe...
At the end of the trial period, an invoice is created (invoice.created).
An hour later the invoice payment is attempted.
If the attempt fails, the invoice enters dunning (per how they've been configured).
However, I would like to "short-circuit" the attempt on the invoice if there is no credit card on file. Instead of failing and entering the dunning cycle, I'd like to immediately mark the invoice as failed (or some other status that allows me to pay for it later).
This way...
A customer on trial who has no intention of continuing (i.e. they never entered a credit card), will not be forced to sit through the dunning process and receive payment failure emails via Stripe.
If they decide to come back, upon entering CC info, I could pay the outstanding invoice via the API and reactivate them on our end.
There doesn't seem to be a straightforward way of doing this. Specifically, while I could process an invoice.created webhook event and then figure out if the customer has a CC on file, I can only mark that invoice as closed, which, to my knowledge, means I cannot reopen it later to pay if they decide to come back.
Has anyone dealt with a scenario like this? It seems like there is no elegant scenario for handling a trial end when a customer has not entered CC info.
I've figured out a workaround. Posting here in case anyone else stumbles upon this issue one day.
Rather than short-circuiting the dunning cycle for an invoice with no CC, I simply let the dunning cycle proceed.
However, I've disabled Stripe failed payment emails from being sent from Stripe. This way, I can decide what emails to send (or not send) upon any payment failure via the webhook.
Now, when I receive an invoice.payment_failed hook, I can check against the customer's ID passed in the event to see if that customer has a CC. If they don't, then I can custom send a "Trial ended" email on my end and suspend the account (again, on my end).
On subsequent failures during the dunning process, I will be able to check if the account was already suspended. If so, I simply don't send any email notification.
The net effect is that a customer gets the "Trial ended" email on the first invoice.payment_failed event, and nothing on subsequent events.
For customers who do have a CC, I can send off a "payment failed" email on receiving each event.
I know you can trigger an approval email to the approver of a document when a certain condition is met. However, is it possible to trigger an email back to the originator of the document when the approver makes a decision. Say PO originator gets an email saying the PO is now approved.
Thanks much
You are looking for the Changes Notification feature. Have a look at http://www.timrodman.com/acumatica-financial-report-change-email-notifications/ for a great tutorial on this.
In your PO case, you would probably only have to set the condition as Status Equal Approved and set the email adresses to receive the message.
When a guest checkout completes successfully, the redirect and webhook postback are both passed parameters indicating a successful checkout. However, what happens if the ACH fails to clear several days later, or is cancelled by the receiver? Is the only way I can determine this by querying the transaction on the expected clearing date, or is there a webhook I am missing?
If this is accomplished by querying the transaction ID, and I check after the expected clearing date, is it guaranteed to not then clear after that?
Dwolla has a Webhook called "TransactionStatus". That Webhook will POST to your server whenever a transaction's status changes. On a typical transaction, you will get 2 notifications: first, that the transaction entered "pending" mode, and then finally when it enters "processed" (or "failed", "canceled") mode.
Here's a page explaining the different statuses a transaction can be in.
Finally, if you decide to opt out for the manual polling method, you should know that as long as a transaction is in "pending" mode, that are no guarantees either way. That said, its very very rare for a transaction to stay pending after its clearing date.