Q: Anyone know any working method, or alternate URL, to create an Authorize.Net Sandbox Account?
After filling out the Sandbox Account form at, https://developer.authorize.net/hello_world/sandbox/ , I received the error message:
URL: https://developer.authorize.net/hello_world/sandbox/
Complete Page Body:
ERROR
The request could not be satisfied.
This distribution is not configured to allow the HTTP request method that was used for this request. The distribution supports only cachable requests.
Generated by cloudfront (CloudFront)
Request ID: eA28WPE73_KAV2p91ixOhETSVWssiFeOdvnr0az40wxLVIT2bDBhBw==
==EOF==
Edit 2017-12-04:
While not an answer to my question (which may be “There is none.”), I ‘mis’-used Authorize.Net’s contact form to request a manual account creation. As opposed to the ~2 days they give for reply ETA, the above form was ‘fixed’ and they replied, “I just tested the page and I could not recreate the error” within ~5 hours.
I’ll leave the question open for a week in case someone knows an answer, and afterwards close it with ‘None.’
Related
I used ACH transfer with plaid and stripe my website.
Bank connections are currently working. However, after connecting their bank account, the user gets a 400 server error that prevents them from being redirected to the dashboard.
I believe the error code associated with this issue is PRODUCT_NOT_READY
https://plaid.com/docs/errors/assets/#product_not_ready.
The server is a node server.
I want to know how I can fix this error.
Regards
Are you tracking the webhook? It seems that the server will send you a WebHook to the endpoint and only after that the resource will be available.
The Plaid server will send you a PRODUCT_READY webhook before you can call /asset_report/get
The PRODUCT_NOT_READY error you linked to is of type ASSET_REPORT_ERROR. If you're using Plaid for ACH transfers, you're probably not using Assets and you're probably getting the PRODUCT_NOT_READY error of type ITEM_ERROR. For that error, the likely causes listed are:
/transactions/get was called before the first 30 days of transaction data could be pulled. [Not relevant to you if you're not using transactions]
/auth/get was called on an Item that hasn't been verified, which is possible when using micro-deposit based verification [probably the cause of your problem]
Like Nikolas L. says, you will need to listen for webhooks, in this case to be alerted when the Item has been verified.
For the past several months I have a native iOS application that uses the embedded signing API to generate an embedded signing URL. My parameter for returnUrl uses a URL with a custom scheme, say, for example, foo. I was using this custom scheme to intercept when the signing is complete and transition to another part of my application. This is now broken and get the following response:
{
"errorCode": "INVALID_REQUEST_PARAMETER",
"message": "The request contained at least one invalid parameter. 'returnUrl' parameter must be an absolute URL."
}
When I try using the schemes http or https the request works just fine. For example:
https://docusign/complete works
http://docusign/complete works
foo://docusign/complete broken
bar://docusign/complete broken
This is in the dev sandbox and I am not aware of this being broken in production. Is this change intentional or a bug? If intentional, why are you breaking the behavior of the client being able to choose their own URL for redirection? Using this custom scheme, I am able to unequivocally determine that my application is responding to a completion event, without having to introspect any other parts of the URL.
This breaking change is a bug that was introduced by mistake. Thank you for your report on it. I'm escalating it.
This issue is now tracked internally as DocuSign IM-32736
Please contact DocuSign customer support and ask them to add your contact information to IM-32736. Thank you.
This bug has now been declared as a release blocker. It will not go to production. The bug is being fixed and tested. It will probably arrive on demo.docusign.net sometime on Friday. I will update this answer as more progress is made.
Update
The bug has been fixed and the fix has been pushed to demo.docusign.net.
Please advise if this is still an issue. Thank you again for reporting it.
This is pertaining to the UPI Payment system in India.
I am using the sample code at https://developers.google.com/pay/india/api/android/in-app-payments to initiate Google Pay App to make UPI Payment.
And everything is working fine.
My concern is:
As all this is at the client end (mobile app), a user (say, hacker) may generate random response values and invoke the server URL to tell the server that the payment is successful. How can I prevent that? How can I ensure that the payment was actually made?
In the provided example, there is a query parameter "url", does Google's server call this URL to update the payment status?
I tried, but nothing happened (I created a page which saves the page URL (Request.RawUrl) in a text file, but on payment the page was not called).
May be Google does call this URL (and I missed something), may be it does NOT; can anyone confirm.
Repeat: My actual problem is how to prevent a hacker from fooling the server that the payment is made successfully.
Note: This is to be my first app, so banks are not ready to provide API/UPI integration.
Paytm provides an api to check transaction status, so not a problem with that.
If not a direct solution, any way around will also work as long as it prevents me from manually checking bank statements.
TIA.
We were implementing UPI payment for one of our client and realized same issue.
We haven't tried Secure Intent to solve the issue. As per NPCI Document, Signed content can be passed thru URI but does not know whether response also contains the signed info to verify its been done.. If it works, we have way to make it secure..
I am using sandbox account for docusign everything is working fine. Now I want do this for LIVE account for this I have followed this URL https://developers.docusign.com/esign-rest-api/guides/go-live-steps#review-failed.
While I am going send request to review my AIP transaction. I am getting response Review did not pass.Error in 3rd step. Compliance with [[linkstart]]API rules and limits[[linkEnd]].
Here is a snap shot of error page
https://drive.google.com/open?id=1O7zCfDGHf5YIbZ0EtnWmr7N3hKjvmApG
I have downloaded a error logs. No error found in this log
https://drive.google.com/open?id=1jXxkf53g9_ELsRnEjF44qrMkDpIuV-dt
This review failed due to a known issue in the automated review process (tracked under DCM-3308). In short, the GetEnvelopes call isn't properly tracked, so the review cannot correctly distinguish between valid traffic that complies with the Polling rule and invalid traffic that does not.
For anyone else who encounters this issue (Specifically, with the GetEnvelopes call appearing in the traffic CSV): First confirm your traffic is not polling for the same resource more than once every fifteen minutes, then reach out to go-live#docusign.com: provide your integration key and the CSV of review traffic.
I was using the following api to get the latest 3 posts from public accounts to show on the website:
https://api.instagram.com/v1/users/{user-id}/media/recent/?client_id={client-id}&count=3
I had created an app to get the client-id.
However from today, this API has started throwing the following exception:
{
meta: {
error_type: "OAuthAccessTokenException",
code: 400,
error_message: "The access_token provided is invalid."
}
}
Could you please let me know as how to resolve this?
Based on the date, you probably have an older app that got hit by the API migration today, like mine. In short, Instagram decided to make developing for their platform WAY more annoying by requiring all API requests to be authenticated per user, even for data that users shares publicly. So you (like me) will likely be redesigning you app entirely.
To tell, log in to instagram.com/developer and click manage clients; then hit edit next to the set of keys your're trying to use. Up near the top, it will have a section called 'Client Status' -- if yours reads 'Sandbox Mode', fun times ahead! Hopefully you interact with less than 10 users and can stay in sandbox mode, otherwise you'll have to write an essay, film a video, and basically plead to get your permissions back (probably in a few months, when some Instagram intern finally digs his way down to you in the pile of applications). If it reads something eles, you've got another problem altogether and should thank your lucky stars.
In the meantime, I guess I'll get back to sending out dozens of emails to the maintainers of our many, many affiliated Instagram accounts to explain the issue and try to get permissions, so provided we get approved by then, all our social media displays aren't broken during a huge event Saturday. Another option might be to use the OAuth-less json response available here, but that might break terms of service.
I have a solution to this. If you are using the same code I am, which appears likely. I was pulling the last two images using this.
https://api.instagram.com/v1/users/{user-id}/media/recent/?client_id={client-id}&count=3
What I did to get this working is the following.
Login to your Instragram account you are using as the application.
Go to the developer (API) area. https://www.instagram.com/developer/clients/manage/
Manage clients. Make sure your website URL is the same as your valid redirect URL.
Add new Sandbox User. Put in the account of the IG photos you want to reach.
Hit this URL: https://api.instagram.com/oauth/authorize/?client_id=CLIENTID&redirect_uri=REDIRECT_URI&response_type=token where the client ID is the same one you used in your previous app above.
You should get back and access token URL. Copy your access token.
Login as your account that you want the IG photos of. The account you added as a sandbox user and go to developer and approve the Sandbox Invites.
Change your original URL above from https://api.instagram.com/v1/users/{user-id}/media/recent/?client_id={client-id}&count=3 to https://api.instagram.com/v1/users/self/media/recent/?access_token=ACCESS_TOKEN with your access token.
This is the IG API Media endpoint documentation: https://www.instagram.com/developer/endpoints/users/
After that, it all worked for me and while you are in the sandbox, you should be able to pull the last 3 photos or at this point, figure out how to read the JSON to do so.
Has your app been approved after the June 1st Instagram platform changes?
http://developers.instagram.com/post/145262544121/instagram-platform-update-effective-june-1-2016
If you want to retrieve the user media file then try this, It's working for me
https://graph.instagram.com/me/media?fields=id,caption,media_url,media_type&access_token=ACCESS_TOKEN
For some reason the token is no more valid. Request it again.
Possible reasons why a token is no more valid:
changed password
verified the account
logged-in from a different country