Can someone tell me if address validation occurs automatically when a label is purchased? I am running in test mode, and it allows me to purchase a label when I type in an invalid address. Will this same behavior occur when NOT in test mode? Or do I have to call shippo.address.validate(<ADDRESS OBJECT ID>) myself and check the status before proceeding with the purchase? I am creating and purchasing in batch. Thanks in advance!
Related
I am working on an iOS app using Amazon Web Services and I am setting up a user data base using the Cognito Userpool. During the sign up process, if a user enters the wrong phone number by mistake and in result isn't receiving a verification code, I am trying to allow them to then enter a new phone number, and update their phone number user attribute. Right now I am using a Lambda function which uses the AdminUpdateUserAttribute function, which is then connected to a APIGateway which allows me to run it from XCode. The function itself works and it successfully updates the phone number attribute.
Problem
The problem that I am running into though, is that after the phone number attribute has been updated with the Lambda function, a verification code is automatically sent to the newly updated phone number via SMS. The verification code is weird though because when I use that code to confirm the user, it doesn't work. Meaning that code is invalid for confirmation purposes. But if I use the Resend Confirmation Code function it will then send a valid confirmation code to the newly updated phone number.
Question
So I guess the questions I have are:
How can I prevent the automatic SMS from sending after I update the user's phone number attribute?
Or, is there a way I can use the verification code that is automatically sent as a confirmation code?
Thank you in advanced.
I've been testing some calls to GetRecurringPaymentsProfileDetails, and am trying to understand the behaviour of LASTPAYMENTDATE. I require this field because I want to differentiate between times where no payment has yet to be made and one has.
There seems to be some odd behaviour, though. I cancelled a payment profile, which happened successfully, and then called GetRecurringPaymentsProfileDetails, but no LASTPAYMENTDATE was present. I called it again and received a 500, and then again and LASTPAYMENTDATE was present. Each call after that (for this particular profile) has not returned any LASTPAYMENTDATE (although the payment is visible in the merchant account if I log in to the UI).
I think I'm going to switch to using the NUMCYCLESCOMPLETED field for my purpose instead, but any ideas why I'm seeing strange behaviour for LASTPAYMENTDATE? Is it a bug? Anyone else noticed this?
Many thanks.
Update: The same profile is now returning LASTPAYMENTDATE.
Update: It's stopped coming back again.
I'm using the callback API to prevent someone selecting a non-UK shipping address. I've supplied a callback url, I've set CALLBACKVERSION to 61.0.
When I go into the sandbox and choose an address I know the callback page is being called as I've added code to email me the values submitted to it and the value returned to PayPal. For anything with a SHIPTOCOUNTRY that isn't GB the response is
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1
I've also tried setting a fuller response in case it doesn't like some required field to be missing
METHOD=CallbackResponse&CURRENCYCODE=GBP&L_SHIPPINGOPTIONNAME0=Standard&L_SHIPPINGALABEL0=Standard&L_SHIPPINGAMOUNT0=2.95&L_SHIPPINGOPTIONISDEFAULT0=true&L_SHIPPINGOPTIONNAME1=Express&L_SHIPPINGALABEL1=Express&L_SHIPPINGAMOUNT1=5.95&L_SHIPPINGOPTIONISDEFAULT1=false&NO_SHIPPING_OPTION_DETAILS=1
But it's still allowing non-UK addresses and just using the shipping options set during the initial set up request.
Any suggestions on where I'm going wrong?
After opening a ticket as suggested by PayPal_Patrick the problem was that I was adding the callbackversion in the wrong place. The full response to reject a shipping address on callback is:
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1&CALLBACKVERSION=61
There are different transaction ID's for Buyer and Seller accounts.
I think this might be an issue caused by the country associated with the buyer account being used. I'm going to reach out to the product team for Express Checkout and see if it is intended functionality or not - I don't believe it would be.
If you want to stay updated on the issue I would recommend creating a ticket to PayPal.com/mts, give me the ticket number, I'll grab it and keep you involved.
I'm using VM 2.0.6 and Joomla 2.5 and the Multisafepay payment gateway.
Whenever a user puts a product in his cart, and clicks on checkout, the user is send to another page completely (Multisafepay's website, so not VM anymore) where he can select his desired payment option - same thing as paypal for example. But, at that time, Virtuemart is already sending an e-mail to the user confirming his order. That e-mail is saying: Thank you for your order blabla, the status of your order is blank..
So, VM is already sending an e-mail before the user payed.
Does anybode relate to this or knows an answer?
VM 2.0.6 is working like this :
when the order is placed that means any one of the shipping and payment method is selected.
and cart have valid data it will create the order and send an email to the user that mentioned
an order has been placed.
You can change
the sending mail section if you need.
One function name with notifyemail (iam not sure the name but it start with notify) in the path:
administrator/components/com_virtuemart/models/orders.php
you can check all your required things like shipping /payment methods are selected before calling this function.
the function should be initiate from cart.php controller in front end.
You can change the point where an invoice copy is sent to the customer in the Store Configuration. Look for Configuration > check out > Default Order Status to send an invoice and make sure you have the Confirmed status chosen.
I seem to have everything setup correctly, however my transactions are not being placed and I get an error saying “There was an error processing your order, please contact us or try again later", when I hit the “PLACE ORDER” button.
I had double checked that the merchant email. partner id, user, vendor and the password are provided correctly and the test mode is enabled.
My payflow pro account is not activated, so its a test account. Is that the reason for my problem ? Any help would be greatly appreciated.
This is a normal process then, I would contact PayPal as they are declining the payment, due to a rule on their side, over max limit, etc.
Other option would be is that you could change the request sent to increase the verbosity of the error but it would only shed further light and would help in troubleshooting.
The request string needs to appended with Verbosity=Medium to increase the output. I believe this can be done via class Mage_Paypal_Model_Payflowpro:_buildBasicRequest() and modify the setVerbosity()
Refer to PayPal Documentation for information.