Anyone encountered an issue where you update the account linking information and the UI does indeed update, but the actual call to the server for authentication stays the same like it was before?
I have update the Client ID for my OAuth 2.0 server and the action still try to authenticate with the old Client ID.
I tried clearing, saving everything again, sending to draft and nothing happens.
The action is still in draft
Related
I have an application in which there are users, issuers, certificates and issues. users are the basic account, and issuers are the upgraded accounts who are able to distribute certificates to users. And distributing of certificates are called issues. The app uses postgres 14.4.
There is something called 'passive issue' in the application, which refers to issue of a certificate to a user that is not yet registered. Passive issue executes a transaction as follows:
check if user exists, if it does ignore it, if it does not, continue
create a passive issue which has awaiting register status
and then when that user actually registers, a trigger fires and updates the issue status.
The problem is that, after checking if user exists, and it does not, but right at that moment the user creates the account, and we try to passive issue, it will throw an error saying user already exists.
There are 2 possible approaches to solve this you might have thought so far:
just catch and check the error and redirect it to normal issuing path rather than passive issue within the api itself
return the error and let client retry the request by sending a request to normal issue path
The problem with above solutions:
It can not be done. Simply because this application uses blockchain, and normal issue endpoint requires the signature of the issuer. Passive issue is specifically implemented to be sent without a signature, and signature is generated on the client-side. And sending the private key to api is NOT even a possibility due to security concerns.
This is possible. This way the client will be noticed that this account registered, and it can prepare the signature and directly send a request to normal issue api. But it requires a longer and more complex implementation with retry logic etc.
And what I think would be the most neat solution in my case is such a scenario of passive issue:
check if user exists, and if it doesn't, lock the insert into the user table for that specific email ONLY
create passive issues for those accounts with await registration status (tx committed at this point and lock is released)
now even if the user tried to register in the middle, it will wait until issues are created and then user will be registered, and then trigger will fire, and since there are passive issues on this user now, it will update them.
So... Long story short: is there a way to put a lock on insertion of non-existing rows? And if there is, is it more feasible than the 2nd or any other possible solution?
I spent the last day and a half researching this problem to no avail. I found many similar problems, but none that exactly address my issue. I am attempting to integrate Payflow Pro with transparent redirect, but cannot successfully complete a transaction. I am using the test environment with a test Payflow Gateway account.
I can successfully retrieve a secure token by posting the following from my test server to https://pilot-payflowpro.paypal.com:
PARTNER=[hidden]&VENDOR=[hidden]&USER=[hidden]&PWD=[hidden]&TRXTYPE=S&TENDER=C&CREATESECURETOKEN=Y&SECURETOKENID=20180916085333999&URLMETHOD=POST&SILENTTRAN=TRUE&AMT=2&BILLTOFIRSTNAME=John&BILLTOLASTNAME=Doe&BILLTOADDRESS=123TestDr.&BILLTOCITY=Testcity&BILLTOSTATE=TN&BILLTOZIP=55511&BILLTOEMAIL=johndoe#test.com&USER1=3&USER2=&USER3=0&USER4=2
to which I receive the following response:
RESULT=0&SECURETOKEN=[hidden]&SECURETOKENID=20180916085333999&RESPMSG=Approved
NOTE: I have configured a Return URL using PayPal Manager, which is why RETURNURL is not included in the secure token request. However, I also have tried with RETURNURL specified, and I have obtained the same end result.
I use the results from the secure token request to create a cc collection form. I input test credit card details using acct# 5105105105105100, then post the following from the browser directly to https://pilot-payflowlink.paypal.com:
fund_id=3&ACCT=5105105105105100&CVV2=555&EXPMONTH=01&EXPYEAR=20&EXPDATE=0120&SECURETOKENID=20180916085333581&SECURETOKEN=[hidden]&feeTokenID=20180916085333999&feeToken=[hidden]
The response is properly redirected to the Hosted Page error URL I have specified in my Payflow Manager Service Settings. My problem is that I do not understand why it is redirecting to the error url with the following message:
RESPMSG=Failed to connect to host Input Server Uri = https://pilot-payflowpro.paypal.com:443
NOTE: The value above is only one part of the response sent to the error page. The rest of the return values include information from my original secure token request, which I would assume could only be returned if a successful connection had been established with the link in the error message??
To clearly state the problem:
I have already successfully connected from my test server to the link specified in the error message, when first I obtained the secure token.
The post that results in the error message was sent from the browser (in this case, on the same physical box as my test server) to https://pilot-payflowlink.paypal.com, which is not the URL specified in the error message.
Finally, the error seemingly occurs during the Payflow process - to my understanding, there should not be a call from my server or the browser to the link in the error message at this point during the process. I mention this specifically to address the many search results I found relating this particular error message to PayPal's requirement for TLS1.2, which is already properly configured on my server (I should mention for the sake of completeness, I do still have TLS1.0 enabled on my test server, but cannot disable it for unrelated reasons. Nonetheless, I was able to successfully connect to obtain a secure token, and my server passes PayPal's own TLS test at https://tlstest.paypal.com/).
I should mention that I also have tried to complete this same transaction on our production server, still using test credentials and test endpoints at PayPal, with exactly the same results. The test server is also set up for TLS1.2 with TLS1.0 enabled, and also passes PayPal's test.
This problem may be the one that pushes me full-on into insanity, so any help really would be appreciated!!
Disabling TLS1.0 has helped others with this issue. If you keep having problems, contact PayPal's support
For anyone who might find this question and be similarly frustrated, I want to share that I was able to solve the problem by creating a new Payflow Gateway test account.
I spent a great deal of time on trial and error solutions with no success, and PayPal Merchant Technical Services was able to duplicate the problem but was also unable to find a solution. Finally, after simplifying my test app as much as possible (two bare-bones HTML forms filled in and submitted manually), I came to the conclusion that there might be something wrong with my test account. Upon creating a new account with new credentials, then inserting them back into my original code, everything worked perfectly.
As of this morning, PayPal MTS is continuing to research the problem, since others have reported similar issues.
For others with similar problems, it is worth noting that I am now able to complete transactions while TLS 1.0 remains enabled.
I've an app which collects leads generated using Facebook Leadgen Ad.
I've a Webhook subscribed for that but for some reason it never sends any requests when leadgen form is filled.
Earlier it was working without any issues.
I noticed yesterday that I received request an hour after forms were filled whereas today I've not received any requests but I do see new leads in the CSV file I downloaded.
Will appreciate if somebody can point me to what can be going wrong here.
Thanks in advance!
Not sure if you have come across this but, there is a testing tool which you can use to submit test leads for a page and see if the lead is getting pushed to your app successfully or not -
https://developers.facebook.com/tools/lead-ads-testing?__mref=message_bubble
If you click on the Track Status button after creating test lead it tell you the status of the webhook ping for the submitted lead.
I am using the PHP Toolkit for PayPal v0.51
I have setup Pay Pal sandbox accounts and done a test to the ipn.php that comes back as working ok.
I have set the config.inc.php to suit my settings
PHP Version 5.3.3-7+squeeze15 mysql and cURL installed all is working fine.
When using with IE
everything works fine, the transaction is returned to the success.php and in the ipn_success.php
I have it updating the database with the information posted back from Pay Pal.
When using Firefox
Everything works fine till I get to the part where it returns me back to the success.php
I get a Security Warning box open up with the below information within it.
Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could easily be read by a third party.
Are you sure you want to continue sending this information?
If I click the warning straight away I get the information posted back and the database is updated.
If I leave this warning for a few seconds, I lose all the information that is posted back to the site for the database.
How can I stop this security warning from showing when using Firefox
The website is using http and not using https so Pay Pay is posting back to a non ssl site.
This is actually a known issue with FireFox that we are currently looking into. If you would like to be notified once the issue is resolved, you can open up a ticket with PayPal's Merchant Technical Support. PPXO-7400
Since PayPal changed their website for developers I can't use it anymore. Before I had some test accounts setup and I was able to go in, create buttons and so-on. Now I have imported my previous accounts but I can't log into them, just getting The requested resource () is not available. 404. If I clear browser cache and cookies, it just tells me to login (using my developer-login details, not the test details) and I can't come in. Their support says clear cache and it works... Stupid PayPal.
Anyone knows what to do?
I tried to update Chrome and Firefox to latest versions and then cleared all cookies/cache then logged into developer account and then tried to login to test accounts.
I always get this 404 message: http://snag.gy/rL5t2.jpg
HTTP Status 404
type Status report
message
description The requested resource () is not available.
Apache Tomcat/5.5.15-150
We're aware of this issue and are working on getting it resolved as soon as possible. In the interim, you can manually remove the '/se/' from the URL included in the screenshot, which will bring you to the correct page (https://www.sandbox.paypal.com/webapps/mpp/home).
Sorry for the inconvenience. We'll get this fixed soon!