I am trying to implement the HMS IAP refund API on my server side, but the API call doesn't work 100% of the time. I'm getting error: responseCode:"12"
This is the sample code I used.
POST /sub/applications/v2/purchases/returnFee
Content-Type: application/json; charset=UTF-8
Authorization: Basic QVQ6Q1YzQ1NPbVlBaGwrZUtRWExtMTBVV2pyWXZHTVF4MmYvcVMya1B0ZElLY3UwaFJrdFNTMmxwdk1FQkIyYldXWGt0REVaR3I4UjFUTTRLMVlmNXdwWU80RG04THdXQWxjaFhEYjBMUjBNTUJtWnFYcGFtazc3THN3UnFJbkhHK28xekdqRzNSMg==
Accept: application/json
Content-Length: 171
{
"purchaseToken": "00000173741056a37eef310dff9c6a86fec57efafe318ae478e52d9c4261994d64c8f6fc8ea1abbdx5347.5.3089",
"subscriptionId": "1581789719266.D40972AC.3089"
}
The weird part is that some refunds work and some don't. Not sure what's going on here. Could someone help me with this issue? Is it possible to use Huawei console to issue refund and confirm it instead?
Unfortunately you cannot issue refund or do the confirmation through HW AGC. You will need to contact Huawei regional operation personal to manually handle it.
Adding IAP refund API into your app is probably the most direct way. As for your refund error "12", it means: The order does not exist. The order in this query may be a historical order. The whole list of error code is Here:
For more HMS IAP Refund information on Subscription refund
and info. on Consumable/Non-consumable
Related
our team needs somehow to detect from our python code messages that got bounced (permanently) and add them to our bounce list in order to not send them in the future anymore. So for example when we send a notification to a non-existent mailbox expected behavior is to receive a bounce mail from the message system which will provide some info for the user and admin diagnostic info. In order to detect permanently bounced messages we tried to use the python library which is called flufl.bounce and during the investigation I was able to detect bounce messages when I scanned my personal Gmail account via IMAP and the library worked perfectly. However, it’s not possible to use IMAP in our use case for our shared mailbox in azure Since basic authentication is not supported anymore and OAuth client credential flow hasn’t been implemented yet for IMAP. Therefore instead of IMAP, we are using Microsoft graph API which supports client credential flow and we are able to get messages from our mailbox. However, the DSN detector is flufl.bounce library does not recognize such messages as bounced even though from admin diagnostic information it’s clear that message is bounced. I've made some investigation and found out that the message does not include the following headers which should present in response in order to recognize it as a bounce. For example:
Content-Type: message/delivery-status
Reporting-MTA: dns; googlemail.com
Arrival-Date: Tue, 26 Oct 2021 02:35:28 -0700 (PDT)
X-Original-Message-ID: <****>
Final-Recipient: rfc822; ********************
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 https://support.google.com/mail/?p=NoSuchUser
Last-Attempt-Date: Tue, 26 Oct 2021 02:35:28 -0700 (PDT)
When I check bounce messages via outlook view source I can find this header, however, graph api response does not contain them. I tried to fetch the eml version of mail via graph api however I didn't find these headers. Is it possible to add them to the response somehow? or should we wait till client credential flow for IMAP will be released?
Thanks for reaching out. To my knowledge, fetching these headers is not currently supported by MS Graph, would you consider filing a feature request on the Microsoft developer platform so this can be looked into?
In the meantime, you might look into using Microsoft Outlook Messaging API (MAPI) to detect bounced messages.
Let me know whether this helps and if you have further questions.
I used this guide to built a showcase - sign in with LinkedIn into a specific site.
Everything worked perfectly until I demonstarted it in front of a wide audience and it broke down :-( It was a great FAIL and I want to know why. Here is what I do:
1.On the sign in page the user may click a Sign in with LinkedIn button and is redirected to similar link:
https://www.linkedin.com/oauth/v2/authorization?redirect_uri=[my_callback]&client_id=[my_client_id]&response_type=code&state=[securely_random]&scope=r_basicprofile%20r_emailaddress
2.The user allows the application and is sent back to my_callback
3.In my_callback I make a POST to https://www.linkedin.com/oauth/v2/accessToken in order to obtain an access token. I use the code sent by LinkedIn, correct client ID and secret. Everything is OK, e.g the response might be:
{
"access_token": [access_token],
"expires_in": 5184000
}
4.I make authenticated requests to fetch the profile data from endpoint https://www.linkedin.com/v1/people/~:(firstName,lastName,email_address)
Headers:
x-li-format: json
Authorization: Bearer [access_token]
I started to get an error 401 occasionally, e.g.:
{
"errorCode": 0,
"message": "Unable to verify access token",
"requestId": "YX21AN6NZG",
"status": 401,
"timestamp": 1483732371224
}
It seems that some of the requests randomly passed nevertheless...
Additional details:
The user is logged in LinkedIn
The user is administrator for the LinkedIn application
I have checked the limitations (throttle limits) at in the application. Available at https://www.linkedin.com/developer/apps. Everything which can be seen is green.
I have tried all advices and hacks from this question
My app is not live
I'm puzzled!
Question: Any obvious mistake?
Question: Is there any hidden throttle limits (or security instruments) for the limitation of the number of access tokens for specific user/app combination? (I'm always using the same user and I tested pretty aggressively before the big FAIL)
UPDATE: In the next two days the Sign in started working smoothly again as described above. No 401-s anymore... :-X I've made no changes to the code base. So is this some kind of throttle limit or just LI was in a bad mood on Friday?
In case someone is curious I got an answer to my problem from LI support:
Unfortunately, we really can't assist with API issues and 3rd party apps. My guess is that there was a hiccup on Friday and you were the victim of bad timing.
I accept the explanation that I was a victim so this answers my question...
I have an access-token that worked to get data through the API, however now it has stopped working. I've carefully read LinkedIn's documentation: https://developer.linkedin.com/docs/oauth2 and have come up with why this can happen.
The docs state, that the user's session is linked with the access-token. Therefore, logging out of the session means the access-token is invalidated. This makes sense because it's exactly what I see happening.
The oauth2 expired-at is just a timestamp of the ultimate time this access-token will be valid. But it can be invalidated at any moment apparently.
Other oauth2 implementations show features for refreshing the access-token, Linkedin does not provide such feature. Therefore a user has to refresh it manually every time. Not sure if this is by design or they haven't got around to it yet. Overall their API feels pretty out-dated.
I am using UberKit which was working very good for me until yesterday.
I can successfully make a GET request to fetch Product Types (returns 4 types of car and 200 code) but cannot fetch Time Estimates data (returns NO error, NO data but 405 code).
According to Uber API Reference page
401 Unauthorized the request requires user authentication (not logged in).
But also according to them, the Product Types as well as Time Estimates do not need access token and as a matter of fact, I do can fetch the Product Types data without access token mentioned above.
So did anybody else here meet this situation before, thanks.
Here is another similar question I posted and I have got the answer from Uber support officially.
It turned out that in my location, which is China, the full production Uber API has not been fully launched.
That's why anyone in China would get such weird response codes.
There seems to be a bug in Instagram API. When I post a request to like a media, I get following response.
{
"meta": {
"error_type": "APINotAllowedError",
"code": 400,
"error_message": "you cannot like this media"
}
}
My code was working fine previously. But now it does not work. I've also tested the LIKE api on Instagram website's API Console. The API Console on Instagram website also returns the same output. Can someone please look into the issue help me.
Here is the sample request that I send through API Console on Instagram website.
POST /v1/media/742359403607622196/likes?access_token=1141855090.1fb234f.1073806ddd2c46d2bbfb3259b1a5ef1c HTTP/1.1
X-HostCommonName: api.instagram.com
Host: api.instagram.com
Content-Length: 0
X-Target-URI: https://api.instagram.com
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Connection: Keep-Alive
Try using another Instagram account for your application.
I got the same issue with the '400' error. I would assume there is an undocumented limit for calls per second or minute, because I started getting '400' error after trying to multithread likes posting.
But in my case the same function works perfectly with access_token from another account (I just made less threads and added some delay for my func).
When you authorise your app with the user to you request like and commenting permissions. When you make the initial redirect to the instagram site to get the code you need a scope parameter for certain permissions, e.g &scope=likes+relationships
I have a specific question about the verification side of Paypal (using the latest iOS PayPal SDK)
From this document: https://github.com/paypal/PayPal-iOS-SDK/blob/master/docs/single_payment.md
This is mentioned:
Send the payment response to your servers for verification, as well as any other processing required for your business, such as fulfillment. Tip: At this point, the payment has been completed, and the user has been charged. If you can't reach your server, it is important that you save the proof of payment and try again later.
And from there is a link to the verify-mobile payments documentation, in which various things are mentioned, i'm assuming this part applies to the iOS SDK (latest)
Looking up a payment using the REST API
You can payment id value in a response to look up a payment by calling the REST API. The following example retrieves a payment in the sandbox:
curl
https://api.sandbox.paypal.com/v1/payments/payment/PAY-5YK922393D847794YKER7MUI
\ -H "Content-Type: application/json" \ -H "Authorization: Bearer
{accessToken}" You should verify that the Payment:
Is approved ("state": "approved"). Contains a Transaction with: An
Amount with total and currency that match your expectation. A Sale
that is completed (in related_resources, with "state": "completed").
The live endpoint is
https://api.paypal.com/v1/payments/payment/{payment_id}.
https://developer.paypal.com/webapps/developer/docs/integration/mobile/verify-mobile-payment/
Got it. So given the above assumptions (which I hope are correct!) what should one do with the details returned from the server? Save them to a database?
The docs seem to be a little vague in terms of this particular subject. This is my understanding of the flow:
1) Make payment.
2) Send payment details to server.
3) Get back payment state from server.
4) Check that it's approved and the other details match up (amount, currency etc)
5) Upon making another payment, check to see if the payment id has already been used? This is another part of my confusion.
Thank you in advance for any assistance. Just would like some clarification in layman's terms to see if I understand the flow correctly.
from the sdk you will get a response which will have a state and id. the id you should save to database for your purposes, because you can always call /payments/id https://developer.paypal.com/webapps/developer/docs/api/#look-up-a-payment-resource and see the details of it. Every id is unique. state will have more information if the payment has been successful or not. Please check documentation. Hope it helps.