Is there a list of what the txstateid values mean when using the getTransactionDetail API?
You will find the corresponding transaction status in the status field of the getTransactionDetail response. To help you fill in the blanks:
1 Transaction failed registration. Either an INVALID or MALFORMED response was returned.
2 User on Card Selection page.
3 User on the Card Details Entry Page.
4 User on Confirmation Page.
5 Transaction at 3D-Secure Authentication Stage.
6 Transaction sent for Authorisation
7 Vendor Notified of transaction state at their NotificationURL. Awaiting response.
8 Transaction CANCELLED by Sage Pay after 15 minutes of inactivity. This is normally because the customer closed their browser.
9 Transaction completed but Vendor systems returned INVALID or ERROR in response to notification POST. Transaction CANCELLED by the Vendor.
10 Transaction REJECTED by the Fraud Rules you have in place.
11 Transaction ABORTED by the Customer on the Payment Pages.
12 Transaction DECLINED by the bank (NOTAUTHED).
13 An ERROR occurred at Sage Pay which cancelled this transaction.
14 Successful DEFERRED transaction, awaiting RELEASE.
15 Successful AUTHENTICATED transaction, awaiting AUTHORISE.
16 Successfully authorised transaction.
17 Transaction Timed Out at Authorisation Stage.
18 Transaction VOIDed by the Vendor.
19 Successful DEFERRED transaction ABORTED by the Vendor.
20 Transaction has been timed out by Sage Pay.
21 Successfully REGISTERED transaction, awaiting AUTHORISE.
22 AUTHENTICATED or REGISTERED transaction CANCELLED by the Vendor.
23 Transaction could not be settled with the bank and has been failed by the Sage Pay systems
24 PayPal Transaction Registered
25 Token Registered
26 AUTHENTICATE transaction that can no longer be AUTHORISED
against. It has either expired, or been fully authorised.
27 DEFERRED transaction that expired before it was RELEASEd or ABORTed.
28 Transaction waiting for authorisation.
29 Successfully authorised transaction.
30 The transaction failed.
31 The transaction failed due to invalid or incomplete data.
32 The transaction was aborted by the customer.
33 Transaction timed out at authorisation stage.
34 A remote ERROR occurred at Sage Pay which cancelled this transaction.
35 A local ERROR occurred at Sage Pay which cancelled this transaction.
36 The transaction could not be sent to the bank and has been failed by the Sage Pay systems.
37 The transaction was declined by the bank.
38 User at bank details page
39 User at Token Details page
I don't think you will ever see all of these (mostly 16s, hopefully), so I wouldn't try and test every outcome (you will be forever, and some of these statuses are caused by downstream failures, or issuer, acquirer etc).
Related
The MQTT 3.1.1 spec, section 3.1.2.4 says
If CleanSession is set to 1, the Client and Server MUST discard any
previous Session and start a new one. This Session lasts as long as
the Network Connection. State data associated with this Session MUST
NOT be reused in any subsequent Session [MQTT-3.1.2-6].
The Session state in the Client consists of:
· QoS 1 and QoS 2 messages which have been sent to the Server,
but have not been completely acknowledged.
· QoS 2 messages which have been received from the Server, but
have not been completely acknowledged.
Meaning the client must discard unacked QoS 1 messages and not reuse any data from them in the new session.
However, there seem to be plenty of examples in the wild of clients resending unacked QoS 1 messages on a clean session reconnect.
Resending unacked messages is almost indistinguishable in this case from sending a new message with the same content, except for the DUP flag - is it wrong for a client to set the DUP flag when retrying unacked messages on a clean session?
Also, surely it's a violation to retry QoS 2 messages on a clean session reconnect, since that could potentially break the at most once delivery guarantee?
We have an utility for sending an email to customers. Currently we are using outlook for sending an emails, But once we send multiple email at a time we get the following error msg.
DEBUG SMTP: MessagingException while sending
com.sun.mail.smtp.SMTPSendFailedException: 432 4.3.2 STOREDRV.ClientSubmit; sender thread limit exceeded
After debugging its found that we can't send 3 mails at a time. So thought another approach to send msgs by queuing the request and process the 3 request at a time while keeping other in buffer.
Note: Don't want to use any msq queuing service (like rabbitMQ etc)
Your suggests/inputs will be really helpful for me.
Thanks
If you are using MS Office SMTP (I guess from the error message), there is a limit on concurrent connection.
Documentation
Under the new limit, up to three concurrent connections are allowed to send email messages at the same time.
I have an application using jms that sends data to an ActiveMQ Artemis queue. I got an exception with this message:
The transaction was rolled back on failover however commit may have been successful
This exception is basically telling me that the message may or may not have reached the queue so I don't know if I need to send the message again. Whats the best way to handle an exception like this when:
I cannot send duplicate messages to applications on the other end of the queue.
and
I cannot skip a message.
I can't state it better than the ActiveMQ Artemis documentation:
When sending messages from a client to a server, or indeed from a server to another server, if the target server or connection fails sometime after sending the message, but before the sender receives a response that the send (or commit) was processed successfully then the sender cannot know for sure if the message was sent successfully to the address.
If the target server or connection failed after the send was received and processed but before the response was sent back then the message will have been sent to the address successfully, but if the target server or connection failed before the send was received and finished processing then it will not have been sent to the address successfully. From the senders point of view it's not possible to distinguish these two cases.
When the server recovers this leaves the client in a difficult situation. It knows the target server failed, but it does not know if the last message reached its destination ok. If it decides to resend the last message, then that could result in a duplicate message being sent to the address. If each message was an order or a trade then this could result in the order being fulfilled twice or the trade being double booked. This is clearly not a desirable situation.
Sending the message(s) in a transaction does not help out either. If the server or connection fails while the transaction commit is being processed it is also indeterminate whether the transaction was successfully committed or not!
To solve these issues Apache ActiveMQ Artemis provides automatic duplicate messages detection for messages sent to addresses.
See more details about how to configure and use duplicate detection in the ActiveMQ Artemis documentation.
I want to record the retry attempts of a proxy service in OSB using report action.
I have created a JMS transport proxy service which would pick messages from an IN_QUEUE and routes the message to a business service which would push the message to an OUT_QUEUE and reports the status (success or failure).
However if there is an error while processing, the proxy service should retry for 5 times before getting failed. To acheive this, I have configured the routing options and gave the retry count as 5 and it works good.
All I want now is to record the retry attempts (using report action) of the proxy service. Please suggest me how to do this.
Logging the retry attempts of a business service is difficult, since it's handled out of the scope of the proxy. About the closest you can come is to set up a SLA alert to notify you when the bizref fails, but that doesn't trigger on every message - just if it detects errors during the aggregation interval.
Logging the retry attempts of the proxy is a lot easier, especially since it's a JMS proxy. Failed processing will put the message back on the queue (XA-enabled resources, you may want to enable Same Transaction For Response), and retries will increment a counter inside the JMS transport header, which the proxy can extract and decide whether to report on it or not.
Just remember that unless you set QoS to Best Effort on the publishes/reports, the publishes themselves will be rolled back if a failure happens, which is probably not what you want.
I couldn't find any push notification document saying we can make xx number of requests per day.
I execute a cron which runs every 5 minutes, and on run it will open a connection, send the notification and disconnect.
Will this create any issues, 5 minutes cron a day means 288 request (or connection open and close). Will apple consider this as Denial of Service attack.
Please advise.
Suppose we need to send 500 notifications at a time then it is not a good practice to open a connection, send notification and then close connection. Instead we can open a connection, put a loop for sending 500 notifications and then disconnect it when all are complete.