I'm working on an integration between a shopping cart and PayPal. I'm using the SOAP API and Express Checkout. What I want to test is the behavior of the system when the shipping address of the buyer is unconfirmed. I've created a sandbox account which is not "Bank Verified Account" and its wallet is empty.
Anyway the address status is always "Confirmed" as seen in the snippet below:
<GetExpressCheckoutDetailsResponseDetails xmlns="urn:ebay:apis:eBLBaseComponents" xsi:type="ebl:GetExpressCheckoutDetailsResponseDetailsType">
...
<Token xsi:type="ebl:ExpressCheckoutTokenType">EC-17S48212F9774382J</Token>
...
<PayerInfo xsi:type="ebl:PayerInfoType">
...
<PayerStatus xsi:type="ebl:PayPalUserStatusCodeType">unverified</PayerStatus>
<PayerCountry xsi:type="ebl:CountryCodeType">DE</PayerCountry>
<Address xsi:type="ebl:AddressType">
<Name xsi:type="xs:string">...</Name>
<Street1 xsi:type="xs:string">...</Street1>
<Street2 xsi:type="xs:string"/>
<CityName xsi:type="xs:string">...</CityName>
<StateOrProvince xsi:type="xs:string"/>
<Country xsi:type="ebl:CountryCodeType">DE</Country>
<CountryName>Germany</CountryName>
<PostalCode xsi:type="xs:string">11111</PostalCode>
<AddressOwner xsi:type="ebl:AddressOwnerCodeType">PayPal</AddressOwner>
<AddressStatus xsi:type="ebl:AddressStatusCodeType">Confirmed</AddressStatus>
</Address>
</PayerInfo>
</GetExpressCheckoutDetailsResponseDetails>
How can I emulate unconfirmed addresses?
Unfortunately, for sandbox environment address will be confirmed. Only way is to test issuing live.
Related
I followed the below link Configure Email Otp to configure Email otp for two step authentication in WSO2 Identity server.
After giving username and password in the login page, we are supposed to be redirected to Email OTP page but we are getting redirected to https://localhost:9443/authenticationendpoint/samlsso_notification.do?status=Error+when+processing+the+authentication+request%21&statusMsg=Please+try+login+again.&SAMLResponse=pZLLbsJADEX3%2FYrR7AN5QZIRGYRaISGVTXksuqncxECkZAaNJ1X7900CETQLNl3a8r332PJs%2Fl2V7AsNFVql3Bu5nKHKdF6oY8p326UT87l8mhFUpX8Wb0hnrQjZ6iXlH2EQRbnvxkmWuBiHUQIhHkKYRp%2BTKSTgcbYiqnGlyIKyKfddL3LcxPH9rReISSCCaBS703fO9j2A3wI0SIrEJTLltVFCAxUkFFRIwmZis1i%2FimZUnI22OtMllxdC0QUattSmAvtY23aK3Dl0owKVLezPn%2BzHciBCYxtoLkudQXnSZGfjewrZX21jwdY0KJ91jmwPZY2Pc6ibvl4%2BR8P%2F57Oo7UktoSgx52N5Bb73GtivkQiOKHfNtgwacXuoDNrF2aGzGXj0gkH7Vvc%2FJH8B.
When we checked the logs, we found the below trace,
TID: [-1234] [] [2017-09-22 13:53:37,664] ERROR
{org.wso2.carbon.identity.authenticator.emailotp.EmailOTPAuthenticator}
- Unable to get the access token org.wso2.carbon.identity.application.authentication.framework.exception.AuthenticationFailedException:
Unable to get the access token at
org.wso2.carbon.identity.authenticator.emailotp.EmailOTPAuthenticator.initiateAuthenticationRequest(EmailOTPAuthenticator.java:158)
at
org.wso2.carbon.identity.application.authentication.framework.AbstractApplicationAuthenticator.process(AbstractApplicationAuthenticator.java:64)
at
org.wso2.carbon.identity.application.authentication.framework.handler.step.impl.DefaultStepHandler.doAuthentication(DefaultStepHandler.java:466)
at
org.wso2.carbon.identity.application.authentication.framework.handler.step.impl.DefaultStepHandler.handle(DefaultStepHandler.java:233)
at
org.wso2.carbon.identity.application.authentication.framework.handler.sequence.impl.DefaultStepBasedSequenceHandler.handle(DefaultStepBasedSequenceHandler.java:175)
at
org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultAuthenticationRequestHandler.handle(DefaultAuthenticationRequestHandler.java:127)
at
org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator.handle(DefaultRequestCoordinator.java:142)
at
org.wso2.carbon.identity.application.authentication.framework.CommonAuthenticationHandler.doPost(CommonAuthenticationHandler.java:46)
at
org.wso2.carbon.identity.application.authentication.framework.CommonAuthenticationHandler.doGet(CommonAuthenticationHandler.java:37)
at
org.wso2.carbon.identity.sso.saml.servlet.SAMLSSOProviderServlet.sendRequestToFramework(SAMLSSOProviderServlet.java:1004)
at
org.wso2.carbon.identity.sso.saml.servlet.SAMLSSOProviderServlet.handleRequest(SAMLSSOProviderServlet.java:160)
at
org.wso2.carbon.identity.sso.saml.servlet.SAMLSSOProviderServlet.doPost(SAMLSSOProviderServlet.java:108)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:650) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at
org.eclipse.equinox.http.helper.ContextPathServletAdaptor.service(ContextPathServletAdaptor.java:37).
Any idea on how to resolve this issue?
This is most likely due to inability to connect your Email provider(server). You can initially do following in order to diagnose,(assuming you are using Gmail)
Verify the "userId", "gmailClientIdValue", "gmailClientSecretValue", etc are valid.
<Parameter name="GmailEmailEndpoint">https://www.googleapis.com/gmail/v1/users/[userId]/messages/send</Parameter>
<Parameter name="GmailClientId">gmailClientIdValue</Parameter>
<Parameter name="GmailClientSecret">gmailClientSecretValue</Parameter>
Try to invoke the email send with different tool (postman) with the API. This is to verify that the API endpoints are reachable from your machine. This is to exclude any network level port blocking, etc.
The problem
I am trying to create an autodiscover script for the users of my website. Currently I am creating a working connection to my mail-server, however my mail server requires SMTP authentication. I am currently sending:
<AuthRequired>on</AuthRequired>
in the full XML file to enable SMTP authentication. This enables the checkmark in the details next to "My outgoing server (SMTP) requires authentication". The bullet list with the two options "use same settings as my incoming mail server" (prefered) or "Log on using" has no option selected.
What I've tried
I have tried adding the POP3 information and putting the following attribute in my SMTP part:
<UsePOPAuth>on</UsePOPAuth>
However that did not work. To create the XML file I have used the following URL: https://technet.microsoft.com/en-us/library/cc511507.aspx
My current XML document
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<Protocol>
<Type>IMAP</Type>
<Server>mail.test.nl</Server>
<Port>143</Port>
<DomainRequired>on</DomainRequired>
<LoginName>me#test.nl</LoginName>
<SPA>off</SPA>
<SSL>off</SSL>
<AuthRequired>on</AuthRequired>
</Protocol>
<Protocol>
<Type>SMTP</Type>
<Server>mail.test.nl</Server>
<Port>587</Port>
<DomainRequired>on</DomainRequired>
<LoginName>me#test.nl</LoginName>
<SPA>off</SPA>
<SSL>off</SSL>
<AuthRequired>on</AuthRequired>
<SMTPLast>on</SMTPLast>
</Protocol>
</Account>
</Response>
</Autodiscover>
I found a very useful article on TechNet which basically explains why this is happening. From what i understood, specifying the SMTPLast property makes Outlook attempt to login to POP/IMAP before SMTP, without actually authenticating SMTP (some servers such as my school's only work this way).
I reproduced the same problem you had with that config but once i removed it, it worked like a charm.
I noticed there isn't a lot of useful documentation about Autodiscover, aka POX autodiscover so here's the xml template that worked for me:
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<User>
<DisplayName>First Last</DisplayName>
</User>
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<Protocol>
<Type>IMAP</Type>
<Server>mail.example.com</Server>
<Port>993</Port>
<AuthRequired>on</AuthRequired>
<LoginName>email#example.com</LoginName>
<SPA>off</SPA>
<SSL>on</SSL>
</Protocol>
<Protocol>
<Type>SMTP</Type>
<Server>mail.example.com</Server>
<Port>587</Port>
<AuthRequired>on</AuthRequired>
<LoginName>email#example.com</LoginName>
<SPA>off</SPA>
<Encryption>TLS</Encryption>
<UsePOPAuth>on</UsePOPAuth>
</Protocol>
</Account>
</Response>
</Autodiscover>
I'm using PayPal Digital Goods checkout with the classic API (signature/password API credentials). Live transactions are working but sometime between Dec 27 and Jan 7 sandbox transactions stopped working, claiming "session expired" when trying to confirm the transaction. Following is the response to the Digital Goods checkout and the confirm invocations:
[08-Jan-2014 20:03:06 UTC] PayPal Checkout-Calling SetExpressCheckoutDG
[08-Jan-2014 20:03:07 UTC] PayPal Checkout Result. Results = TOKEN:EC-38C423050J138841W TIMESTAMP:2014-01-08T20:03:07Z CORRELATIONID:381d15bad3eaa ACK:Success VERSION:84 BUILD:9187650
[08-Jan-2014 20:03:07 UTC] RedirectToPayPalDG Header=https://www.sandbox.paypal.com/incontext?token=EC-38C423050J138841W
[08-Jan-2014 20:03:14 UTC] PAYPAL GetExpressCheckoutDetails TOKEN=EC-38C423050J138841W
[08-Jan-2014 20:03:15 UTC] PayPal Confirm--Failed. Results = TIMESTAMP:2014-01-08T20:03:15Z CORRELATIONID:2b45bb61f3787 ACK:Failure VERSION:84 BUILD:9187650 L_ERRORCODE0:10411 L_SHORTMESSAGE0:This Express Checkout session has expired. L_LONGMESSAGE0:This Express Checkout session has expired. Token value is no longer valid. L_SEVERITYCODE0:Error
Note the timestamps: the error return is 9 seconds after the checkout timestamp (when the user process started).
It looks like the classic API to the sandbox is broken. Anyone else seeing this, and if so is there a solution?
Its a different correlation or even a different session.
Problem solved--my error in managing credentials.
We had paypal setup all working for PayPal API and Payflow pro then we had to change from a Australian account to a UK account. But now the Pro side gives this error response. We've got limited access to the paypal account it self.
Partner: xxxxxxx Merchant Login(Vender): xxxxxxxxxxxx User: xxxxxxxxx
Password: xxxxxxxxxxxxxxxxxxx Host Address :payflowpro.paypal.com Host
port=443
This is the request we are sending to PayPal:
PARTNER=xxxxxxxx&VENDOR=xxxxxxx&USER=xxxxxx&PWD=xxxx&TENDER=C&TRXTYPE=R&ACTION=A&ACCT=xxxxXXXXXXXXxxxx&EXPDATE=xxxx&COMMENT1[16]=Regstration
- FS&START=02062014&TERM=0&CVV2=xxx&AMT=35.00&PAYPERIOD=MONT&MAXFAILPAYMENTS=0&RETRYNUMDAYS=2&PROFILENAME[14]=xxxxxxxxxxxxx&COMPANYNAME[2]=FS&NAME[12]=xxxx
xxxxxx&FIRSTNAME[6]=xxxxxx&LASTNAME[5]=xxxxx&PHONENUM=xx12345678&EMAIL[24]=xxxxxxxxxxxxxxxxxxxxxxxx&STREET[15]=xxxxxxxx
Street&CITY[7]=xxxxxxx&STATE[3]=NSW&ZIP=xxxx&COUNTRY=AU&OPTIONALTRX=S&OPTIONALTRXAMT=35.00
We are getting the following error response from PayPal:
RESULT=1000&RESPMSG=Generic processor error: 11581-Profile description
is invalid
Google has not really helped. I am hoping a few smart SO guys can assist.
Thank you,
Warren.
I've got my own box sitting in a rack. It's Win2000 running CF 7 and using the rack company's smtp server. I can't send emails. When I try, they simply go to the undeliverable email folder. Support says my server is sending a non-verifiable helo message. So their smtp server wont send it.
It being CF 7, the admin has nowhere to specify U/P for auth. However I SHOULD be able to do that within the tag. When I do, I get no errors but the mail goes to the undeliverable folder.
CODE:
<cftry>
<cfmail to="jxxx#yahoo.com"
from="jxxx#xxx.com"
subject="xxx.com Sign-up"
server="smtp.xxx.net"
port="25"
username="valid-account#xxx.net"
password="password" >
This is a test - with server specified
</cfmail>
Success w/ server user defined
<cfcatch type="any">
<strong>ERROR: #cfcatch.Message#</strong><BR />
#cfcatch.Detail#
</cfcatch>
</cftry>
<cftry>
<cfmail to="jxxx#yahoo.com"
from="xxx#xxx.net"
subject="xxx.com Sign-up" >
This is a test - without server specified
</cfmail>
Success w/o server user defined
<cfcatch type="any">
<strong>ERROR: #cfcatch.Message#</strong><BR />
#cfcatch.Detail#
</cfcatch>
</cftry>
I don't know much about mail servers...
Any ideas?
This could be an issue with DNS and the inability of the receiving system to either do a reverse DNS lookup or maybe it isn't in DNS at all.
another possibility is that non-verifable Helo means that you don't have FQDN associated with the system (perhaps your system name does not have a domain associated with it?) (ie. helo me) probably going to be bounced versus "helo me.somewhere.com".
so - don't think this a CF issue from a coding perspective - something that is related to your system setting (FQDN perhaps) or DNS in your location. Most anti-spam / anti-open relay settings are going to look at DNS for some level of validation.