I have inherited an MVC application that is integrated with Authorize.NET to pass user to their SIM solution to process payment. I am in the process of refactoring the application and I am reusing the "Transaction Key and Fingerprint Hash" logic to send a transaction request.
I am using my client's Merchant Account Login Key and Transaction Key to send a test transaction request to the https://test.authorize.net/gateway/transact.dll sandbox environment and I receive the following error:
Error 13: The merchant login ID or password is invalid or the account
is inactive
Does my client's merchant account need to be configured to allow test transactions? Or do I need to create separate Authorize.Net SIm credentials to test sandbox transaction request?
Any other Authorize.Net configurations that I should focus?
The URL you are hitting only works for specific test accounts (i.e developer accounts). Using actual Authorize.Net production account credentials will not work in the test environment. If you want to test their specific account you will need to use the production URL and set it to test mode to do your testing.
If you are just doing dev work and want to make sure your code works correctly you should register for a developer account and then you can use that test URL for testing.
Related
I am looking into developing integrations for the Acumatica Cloud ERP. I am developing a SaaS product on Azure which extracts accounting data from various sources. From the documentation provided by Acumatica, I can see that the API connects to a local instance of Acumatica. If I were to connect to a local instance I would need to use some sort of gateway which connects to a local machine. I also had to install a local instance myself to be able to create a client application and use OAuth 2.0.
I am having issues to understand how to create integration with Acumatica.
Do I need to know the instance name / URL of each of my clients? Do I need to have a local instance running to be able to use Acumatica APIs? Can client Acumatica instances be publicly accessed? If the client using authorization code flow, authorizes my application to extract data from Acumatica, what is the Acumatica ERP URL that I should be using? Mine or the client's? The documentation always uses localhost to connect to an API.
If you use any of the Apis provided by Acumatica:
Contract Based REST (Recommended)
Contract Based SOAP
Screen Based SOAP
You only need the a set of credentials and the URL of the site to communicate with it from the outside. By set of credentials I mean that the credentials that you use need to be able to access and perform the appropriate action on the Acumatica screen that you want to integrate with.
You can find more information on how to do so on the help web site at the following link:
https://help-2019r2.acumatica.com/(W(12))/Help?ScreenId=ShowWiki&pageid=ff22837c-cd3a-410e-b768-88ca6e53b165
It is the Development Integration Guide
Edit
Since you are mentioning Authorization Code Flow in the comment, here is the link that contains more information
https://help-2019r2.acumatica.com/(W(14))/Help?ScreenId=ShowWiki&pageid=ff780860-09c2-46c9-bdd7-c6c3b1fc442c
On that screen you will see the following information:
After the user is authenticated in Acumatica ERP, the client application receives an authorization code, exchanges it for an access token, and then uses the access token to work with data in Acumatica ERP.
Which means that even if your application does not handle the user credentials, the users will need a set of credentials in order to connect the application to the Acumatica site. The user used here will defined the access rights that the application has.
I have built an integration with the Docusign API, but am unable to successfully complete the JWT auth flow with our production account.
Everything works fine in our sandbox account - I went through all the steps described in the docs (https://developers.docusign.com/esign-rest-api/guides/authentication/oauth2-jsonwebtoken),
and successfully promoted the integration key to our production account.
However, with the production account, running through the same code to initiate the JWT results in a 400 Bad Request error, with no additional information about the nature of the failure. I've double checked that we are using the correct oauth base domain (what Docusign calls aud) and that RSA keys and redirect URLs are correctly
configured for the production account.
I've also gone through all of the "go live" steps, except for one which mentions migrating users, since it doesn't seem
like this functionality is available on our production account dashboard. On the sandbox account, which has all enterprise features enabled,
the sidebar has a section for "Users and Groups" but there is no such section on our production account.
I'm wondering if the root of the problem is that our production account, which is the Basic API level account, doesn't have adequate permissions
to support the use case I'm building for.
Unfortunately I can't get a straight answer from either account reps or tech support folks as to whether this is true.
are you trying to use the same RSA key you used in Sandbox in Production by any chance?
Also, did you actually get your IK certified and active in production?
I started composer rest server in multi user mode, using github oAuth authentication. I opened one session in chrome and one in firefox (to emulate as two different users) and authenticated using github. Now in one browser I wish to use one network card and in chrome another network card. Now when I import a network card in firefox same is reflected in Chrome as well. Doesn't it defeats purpose of authourisation ? So if one user is using its network card to perform transaction the other user will also be using the same network card as its been set as default for composer rest server. How to deal with scenario ?
The default is set at the REST Client - not the REST server. You're consuming the REST APIs as a client - as the two different blockchain identities (contained in each of your business network cards). Once a client has authenticated to the REST API, that client can add Blockchain identities to a wallet. The wallet is private to that client, and is not accessible to other clients. When a REST client makes a request to the REST server, a Blockchain identity in each clients wallet is used to digitally sign all transactions made by that client (because the identity is set as default, at the time).
The github authentication scheme is a 'delegated' authentication scheme and is using a client application (id and secret) authentication mechanism to enable a client to use the REST APIs and get a token, without needing to authenticate as a user every time.
I had this same problem. Configured the composer rest server with multi user using a jwt strategy, but I was seeing the same wallet (and the same default card) regardless of which user was logged in.
I found that the loopback-component-passport package which largely manages the wallet data was importing my users correctly, but they were all being associated with the same identity because the identity id was taken from the COMPOSER_PROVIDERS config and not the signing in user.
To fix it I modified loopback-component-passport/lib/models/user-identity.js.
Look in the UserIdentity.login method around line 100 where the userIdentity is being populated.
Change:
provider: provider,
to something like
provider: profile.sub,
depending on your payload / user profile.
After that each user will have their own identity registered in your loopback database and each signed in user should have their own wallet.
I have an application that uses the DocuSign API (the NodeJS SDK, specifically) and got everything working perfectly on the demo sandbox. The Docusign people certified the app for production.
I followed the "Go Live" documentation and changed the endpoint from https://demo.docusign.net/restapi to https://www.docusign.net/restapi in my apiClient.setBasePath(), however, I'm getting a USER_AUTHENTICATION_FAILED error.
The username and password have been set to the same as on the demo sandbox, so I know they are correct. Also the IntegratorKey is the same as the demo sandbox, and after they certified the app, I can now see it in my production account.
Here is a pastebin of the error
Any assistance would be greatly appreciated!
This is most likely a baseUrl issue, you should be parsing the baseUrl that is returned in the login API and using that as the base for subsequent API requests in production.
In your developer sandbox (ie demo) environment all URLs start with "https://demo.docusign.net/" which is why all your test calls work in demo, in the live production system the account URL will vary based on user and which data center their live production account resides on.
You need to parse the baseUrl value that is returned from the Authentication:login API and use that as the base for subsequent DocuSign API requests, or use the base_uri value if using OAuth.
I have been working on IBM Maximo Anywhere apps such as Work Approval and Work Execution for sometime now have few queries regarding the login mechanism used by these apps. To be specific as per my understanding anyone having access to maximo on that particular environment can login into the anywhere apps - is that a correct statement? and if yes then how does it work in a disconnected state? If for any reason maximo is down will it mean that the app will not be able to authenticate a user and hence unable to login as well? And alongwith that is there any other kind of authentication done for example LDAP etc? Are there any different kinds of login failure messages that are displayed depending on why the app isnt able to let the user login? or is it a common one saying "Login Failed"
The first time the user ever logs into the application, they do have to have a connection to the Maximo server to authenticate. We also validate that the user is authorized to use this particular mobile app. We have a security group for each mobile app that the user must be a member of. After the authentication and authorization finishes, we download, store, and sign the locally stored data with the username/password combination, so that on subsequent login attempts, if the server is down, we can fail over to the locally stored data. This also guarantees that the locally stored data is protected.
We support all of the types of authentication configuration that base Maximo supports.
More information here:
http://www-01.ibm.com/support/knowledgecenter/SSPJLC_7.5.0/com.ibm.si.mpl.doc_7.5.0/security/c_authentication.html