I have set up negative testing for an account then set the error code desired as the Transaction Amount Field for example 106.06 to invoke error code 10606 "Buyer cannot pay” no errors are returned the order is processed.
If I try another error code 10539 “This transaction cannot be processed”. An error is return and the order is not processed.
I am using the The US site error codes: http://www.paypalobjects.com/en_US/ebook/PP_APIReference/Appx-ErrorCodes_and_Messages.html and we are in Australia are these the correct error codes?
Any ideas what is causing this? Is this the correct way to use Negative Testing in the sandbox?
Thanks
I know this is late but I stumbled across the answer for me.
You didn't specify the API Name you are working with DoExpressCheckoutPayment and according to Paypal's Negative Testing Docs we are supposed to use an AMT field and
To trigger an error condition on an amount-related field, specify a error code value as a number with two digits to the right of the decimal point. For example, specify a value of 107.55 to trigger the 10755 error.
I found their information to be completely false! What I finally got working was to use PAYMENTREQUEST_0_AMT and NOT use a decimal.
So here is what I came up with
USER={yourUID}&
PWD={yourPSWD}&
SIGNATURE={yourSig}&
TOKEN={yourToken}&
METHOD=DoExpressCheckoutPayment&
VERSION=119&
PAYMENTREQUEST_0_AMT=10486
Edit:
I later found a better option specifically for the Payment Method Refused (10486) that I mentioned above. Take a look: https://developer.paypal.com/docs/classic/express-checkout/ht_ec_fundingfailure10486/#testing-saleorauth
Related
I'm trying to signup to a site I created with AWS Amplify. I added Auth and clicked to allow signing in with both email and phone number. However, when I try creating an account, I get an error saying the phone number format is incorrect. So far I've tried:
+17184625510
7184625510
718-462-5510
etc
but I consistently get the following error. Any help would be appreciated!
According to AWS Cognito, The phone number must be in E.164 format. eg. "+12065550100".
This is a known bug in the Amplify UI which you can read more about in the corresponding GitHub Issue where there is also a proposed workaround for the problem that you can try until the problem is fixed.
The problem is that the +1 that is entered as a default for the country code is undefined in the code. Everything currently works if you switch from +1 to another country code (or to another country code and back to +1 again). If your users are not in the +1 region they probably won't notice, otherwise take a look at the workaround.
I'm new to API testing through postman and i'm currently trying to figure out how to clear down my collection variables between automated tests.
Here is my code below - Thanks so much for anybody who can point me in the right direction.
Warning :
pm.collectionVariables.clear()
will delete all your collection variables:
pm.collectionVariables.unset("variablename")
will delete that particular variable.
so if you just want to reset the value to initial value then:
in the first request add:
pm.environment.get("resetValue") ? null:pm.variables.set("resetValue",pm.collectionVariables.toJSON().values)
Here we store data only if resetValue variable is not set
And in the last request:
pm.environment.get("resetValue").forEach((a)=>pm.collectionVariables.set(a.key,a.value))
pm.environment.unset("resetValue")
This make sure you don't set resetValue incorrectly if you are running first request multiple time
you can also use pm.variables if you don't any variable to be affected , thats the better way
I'm working with moment and moment-timezone and I don't get it. Can anyone explain me why this happens?
THIS (which is what I want):
moment('2018-11-28T00:00:00.000-02:00').toISOString()
Prints 2018-11-28T02:00:00.000Z
BUT:
moment('2018-11-28T00:00:00.000').zone('-02:00').toISOString()
moment('2018-11-28T00:00:00.000').utcOffset('-02:00').toISOString()
Both print 2018-11-27T23:00:00.000Z
PD: My zone is GMT+1.
Why are different? it is not supposed to be equals?
How do I set the offset (not in the constructor but with a method after I have de moment object)?
Thanks! BR
As I can see, you want to keep the existing time of day when using utcOffset method. It accepts a second parameter, which is a boolean. As the documentation says:
Passing true will keep the same local time, but at the expense of choosing a different point in Universal Time.
// "2018-11-28T02:00:00.000Z"
moment('2018-11-28T00:00:00.000').utcOffset('-02:00', true).toISOString();
For more information check the documentation
I am logging some custom events on Firebase Analytics, but some errors keep getting logged for automatic events (such as screen_view) along with the custom events, whether I call them explicitly or not. When I log regular custom events (a button click, for example), I can see them on DebugView without any errors.
I have validated the rules for names (maximum of 36 chars for event key, maximum of 100 for value) as this answer from Chintan points and confimed that no event has reserved names.
I keep getting the error code 13 - which means Event name is reserved, according to the Analytics Error Codes.
Any ideas of what might be happening? Anybody facing the same issue?
Here's how the error is shown at DebugView:
Thanks in advance!
Edit:
Adding a piece of the log, as requested:
Can you check to see if you are using your event names prefixed as "firebase_", "google_" or "ga_"?
As per the official documentation **The "firebase_", "google_" and "ga_" prefixes are reserved and should not be used.**
According to the API docs for Analytics.Event, screen_view is a reserved event name and cannot be used for logging your own custom event.
I have created a account in Google Tag Manager, and I am very new to it. My Container ID code is is GTM-XXXXXXX ( 7 characters ).
I am getting an error about "Invalid or missing account ID"
I read it on different blogs that the error is due to 7 characters in the ID. But I did not understand properly if the error can be ignored or debugged.
Thanks in advance.
According to Google this is a false error and it's going to be resolved in future.
See this link in Invalid or missing account ID section.
NOTE: If your container ID (i.e. what’s referenced here as ‘account ID’) is of format GTM-XXXXXXX, where the portion after ‘GTM-’ is longer than 6 characters, you may see this error unnecessarily. This false error will be resolved in a future update. In the meantime, as long as your container ID follows the correct format as described below, you may ignore this error.
You can ignore this error.