For my ticket to DocuSign support (Case #: 05646003, Account #: 7824722-na2) that I got no answer for it, I mentioned my issues here:
Generally, the Issues that I have:
When I activate the account by the invitation link, an Integration Key will be added to my account but sometimes it disappears. Also, a button that switches the users sometimes appears. This condition takes a long time for us to track the issues (My account is not a premium account and I am just invited by another premium account)
I use these APIs to access the envelopes:
https://demo.docusign.net/restapi/v2/accounts/xxxxxxx/envelopes?from_date=2019-12-20
https://demo.docusign.net/restapi/v2/accounts/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/envelopes?from_date=2019-12-20
I have added 22 envelopes there but when I try to "Submit for Go-Live" it says that I don't have 20+ demo transactions.
I am using those APIs with my Account ID. I followed the instruction to generate an access token using the integration key and the client id, but the code didn't work for "Authorization - Bearer".
I also couldn't find any working instructions that describe "how to migrate from Demo to Production" with details. I have checked all of those pages in the documentation but all of them didn't work.
I have read the documentation but the solutions that are mentioned there didn't work for me and I need details for solving these issues.
I should note that currently, my codes are working in the Dev environment.
I used this link to generate the code:
https://account-d.docusign.com/oauth/auth?
response_type=code&scope=signature%20impersonation&client_id=1b8f72eb-8667-4e0e-...&redirect_uri=https://site.test
The result was:
https://site.test/?code=eyJ0e...
Now I need to know what are my:
- Account ID
- Access Token
- Base URL
NOTE: You cannot use the token generator that is on the developer center website when you go Live. Please ensure you actually use tokens from Production when you authenticate to your app in production.
Masoud, for help with going live you can email to :
go-live#docusign.com
The general documentation about Go Live is here:
https://developers.docusign.com/esign-rest-api/guides/go-live
You can find further information here:
https://developers.docusign.com/esign-rest-api/guides/go-live-steps
Related
Stack Overflow please do your magic..
The Story :
We are using laravel and use the laravel package (imdhemy/laravel-purchases) in-app purchases to use the google billing feature and the app store in-app purchases.
It is running well in the app store but in the play store still failled.
We have followed according to the instructions in the link
https://imdhemy.com/laravel-iap-docs/docs/credentials/google-play
everything goes smoothly except when it validates.
When i tried to call below end point to Checks whether a user's subscription purchase is valid and returns its expiry time.
https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/purchases/subscriptions/{subscriptionId}/tokens/{token}
However always show up an error 400
enter image description here
What we've done :
Create a ticket to Google, but there has been no response from Google after the last update 3 weeks ago.
Tried using another developer account and surprisingly it works normally.
enter image description here
The Question :
Is there something wrong with my developer account settings? Because I've copied the settings with the account that works fine.
I'm fairly new to the PayPal API and am a bit confused about using API signatures to attach to the REST API. I'm creating shopping cart software, and I'd like to allow merchants using the software to attach the system to their PayPal account using their API using PayPal username, password, and signature. They'd enter this information into the account settings when setting up their cart.
On the merchant's side, it seems like this is easily possible, and says to do this to grant API access specifically to shopping carts:
htttps://paypal.com/us/cgi-bin/webscr?cmd=_profile-api-access (once logged in as a merchant).
I personally am using PHP to call CURL, though that probably is not important. What I don't understand is that in the REST API documentation, including the "make your first call" doc, it notes I should send my "clientid" and "secret," but not the merchant's "username","password," and "signature".
https://developer.paypal.com/docs/integration/direct/make-your-first-call/
Now, when I originally logged in as a developer, I was able to obtain my "clientid" and "secret," but that was for my application. I've successfully made test calls with them, using PayPal's test pages. But these of course seem to be for me, not for a particular client.
Now the "Classic API" documentation does have information on connecting to the SandBox using the merchant's info.
https://developer.paypal.com/docs/classic/permissions-service/ht_permissions-invoice/
So I think I'm just mentally missing something, or misunderstanding something fundamental. Assuming I have both my developer credentials, and the API credentials of a merchant, what are the general steps in making a payment to the merchant (not me). What's the logical step I'm missing?
Thanks much to anyone who can help.
Unless corrected by Paypal folk, this seems to be the flow (just went through it):
Ask the merchant to add you as a User, I suppose with API access privileges (only)
They will set your user id and pwd, which they should then provide to you.
You'll then login with that User Id (not an email address) into Paypal (at this point, you're a "user" of that merchant/account) with whatever privileges your merchant provided you.
create the App in the developer site for your merchant - you'll notice that when you get there, it's the Merchant's name displayed (it's not "your" developer account)
At this point you should be set (sandbox and live REST credentials of the merchant from the app you created). One thing I noticed (good) is that it somewhat already helps you see what "live privileges" the account has..so it helps guide you as to what to integrate (scope) and/or advise your merchant to do - e.g. may or may not be eligible for direct credit card payments (only Paypal account payments).
Hth..
#EdSF and anyone else looking into this, I just received a response from PayPal merchant help. Turns out you were spot on Ed. They don't have this ready for REST. Seems pretty odd given that they're 1.) pushing REST on their developer site but 2.) showing that the signature set is how to connect to a shopping cart on their merchant side.
So answer is to use the old API for now, or have them go through the extra hoops of the steps you/they mention, instead of following the directions on the PayPayl site :-P Oh well. Their response in full below.
Hi ...
I am writing this email regarding your questions on PayPal Permission Service. Unfortunately the Permission Service is not available in REST API; however I will file feature request to our development team for their further consideration.
It is not possible to use API username, password, and signature in REST API because they are actually not the correct credentials. REST API uses Client ID and Secret for integration. If you develop your application for other merchants, you can ask them to obtain Client ID and Secret by creating apps in PayPal Developer Portal (https://developer.paypal.com). Here's the steps:
1) Go to http://developer.paypal.com and log into the website with PayPal account's login
2) Click 'Dashboard'
3) In the My REST apps page, click "Create App"
4) Enter the App name, and click 'Create app'
5) You should be able to see 'Client ID' and 'Secret' for 'sandbox credentials'. If you want to integrate with your live account, click 'Show' at the Live Credentials section.
Hope the above information helps. Thanks.
Sincerely,
...
Merchant Technical Support
PayPal, an eBay Company
I was following these articles: Verifying Back-End Calls from Android Apps and Stopping Vampires using License Verification Library (from 24:57 to 25:34) to implement an In-App Purchase verification system for our Android apps.
I am a bit confused about how this works end-to-end and what we can assume about the generated token from calling GoogleAuthUtil.getToken() with the first email address found--when AccountManager returns more than one account. My questions are as follows:
Should we assume that any e-mail address used by the user to buy our
app will generate the same token (i.e., same user + app ==> same
token)?
If the answer to question 1 is no, is there a way to launch in-app
purchase for a particular account/email?
It looks like Google is picking the first e-mail address returned by
AccountManager for its in-app purchase dialog. Can we assume that
this won't be changed by the user after in-app purchase dialog is
launched? How do we find out if this changed after the in-app
purchase returns?
What should we store in our database to identify this user? Is email
address and/or token allowed? When does the token expire?
The java-client library looks very promising and powerful at first
read. But, a number of things remains confusing. Is there an article
that describes the end-to-end scenario--from an app initiating a
call to a back-end server through launching the in-app purchase
dialog, getting the result and closing with commits on the server?
What articles are the most useful for accomplishing this on Android?
The main issue we are trying to solve is to to get the full picture.
We've gotten the idea that we can avoid requiring userid/password by using the java client features and using tokens. We have registers our project (both the web app and android app on the same project) per the instructions for Google API Console. We have the php java-client for Google Play Service on our back-end server. We got our Android app to generate a token using the first email address and then call the in-app purchase dialog and handle the user response at the end of the dialog. We've got the parts. Now, we need to glue everything together. We are at the point of integrating with the back-end server. E.g., What is Redirect URi supposed to point to in our server? We've got a php url that we do http post messages to for our server app. We've included the code example for Google API client example--with client-id, secret, simple api key, etc. filled in--as an include to our php. But, what should we put in the redirect uri (we are missing a usage instruction for the example code)?
Also, we want to avoid having the e-mail used for the in-app purchase be different from what we log on our server database as the address the user used to buy our app; if the address is the correct thing to track, we want it to be the same as what was used for the purchase. This could be frustrating for our user if we make this mistake and prevent them from the features they paid for. We don't want to make this mistake and need some clarification on how Google Play Service works. If we initiated the server part of the workflow to get app Nonce / Payload / Credentials for the first e-mail address on the Android device, we would want that address to be used throughout the workflow. If the user changed this along the line, we want to be aware of this and gracefully recover. So far the articles have been helpful but incomplete. Any insight/suggestion is appreciated.
I want to integrate moneybookers api in my web site.
I have created an account on moneybookers.
To integrate moneybookers API, i need secret word under Merchant tools.
But where is “Merchant tools” and where is “secret word”?
I have attached two screenshots of member panel on moneybookers.
This is in my account-
But from the tutorial-
http://wyday.com/blog/2011/automate-moneybookers-skrill-using-status_url-ipn-php-asp-net/
The screenshots to Create a “secret word” is-
You actually need to contact merchantservices#moneybookers.com and ask for the things you cannot find. That's what they also write in their manuals.
... please contact your account manager or merchantservices#moneybookers.com.
The site Moneybookers is now known as Skrill (bear that in mind as some of the following information might be confusing elsewise)
Skrill (formerly Moneybookers) [...]
Taken from this Wikipedia article.
Anyhow, you want to access the Merchant tools of Moneybookers/Skrill. To achieve this you need to update your Skrill account to a business account (often referred to as "Moneybookers merchant account"), otherwise you're not able to a.) access the tab "Merchant Tools" and b.) therefore set a secret word (which will be available on the "Merchant Tools" tab.
Screenshot taken from this source
To create a Moneybookers merchant account, please check the two following links for further reading purposes:
Check out this tutorial by ConfTool; only Step 1 and 2 matter as Step 3 is specifically for ConfTool Pro and thus not relevant for you.
Analog to the last tutorial, just look at the Moneybookers related part.
If you have any problems with the process, I highly suggest you to look for Skrill related tutorials as "Moneybookers" returns old (most often outdated material).
Today at work I was asked to investigate a problem with contacts export from Hotmail.
It was working last month when i wrote the library. For my surprise it indeed was not working. I investigated a bit and i noticed that Microsoft has done some updates to their API. The scopes were changed ... and the permissions that comes with the scopes. Here is the line that bothered me
WL_Contacts.View -
View information about a user and the user's friends, with the exception of email addresses.
They stripped the priviledge of obtaining contacts email addresses :(
What i have to do in order to get the e-mails back so i can use my exporter again ?
Do you have problems with your contacts importers ? If not, what are you using ? Which scopes ? Are you doing separate requests for each user ?
First of all, you can find tons of information about the new Windows Live Connect API here.
Here you can find version 5 of the API documentation.
If you want to sign up and create a Application you can do that here.
I hope this is enough to get you started (unless you've already found the provided links).