I've got a strange issue with PayPal's Sandbox / API V2.
After creating an order with the AUTHORIZE intent (pre-auth). I'm taking the user to the APPROVE URL, and after selecting the payment method PayPal says that it's redirecting me back to my redirect_url, but instead it just reloads the payment selection screen.
I don't know what's wrong.... This is what I'm passing directly to the API:
curl -v -X POST https://api.sandbox.paypal.com/v2/checkout/orders \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <my-access-token>" \
-d '{
"intent":"AUTHORIZE",
"description":"Description goes here",
"soft_descriptor":"Descriptor",
"purchase_units":[
{
"amount":{
"currency_code":"CAD",
"value":"351.75"
}
}
],
"order_application_context":{
"return_url":"redacted_for_privacy",
"cancel_url":"redacted_for_privacy"
}
}
That call is obviously working as PayPal is returning the CREATED response. I have looped through the returned HATEOAS links and redirected the user to the approve URL ... Then the problem starts...
API response is:
{
"id": "8KF74291SN313461D",
"intent": "AUTHORIZE",
"status": "CREATED",
"purchase_units": [
{
"reference_id": "default",
"amount": {
"currency_code": "CAD",
"value": "351.75"
},
"payee": {
"email_address": "sb-iuaiy3198427#business.example.com",
"merchant_id": "DXYXG2JAU3SQQ"
}
}
],
"create_time": "2020-09-15T05:13:59Z",
"links": [
{
"href": "https://api.sandbox.paypal.com/v2/checkout/orders/8KF74291SN313461D",
"rel": "self",
"method": "GET"
},
{
"href": "https://www.sandbox.paypal.com/checkoutnow?token=8KF74291SN313461D",
"rel": "approve",
"method": "GET"
},
{
"href": "https://api.sandbox.paypal.com/v2/checkout/orders/8KF74291SN313461D",
"rel": "update",
"method": "PATCH"
},
{
"href": "https://api.sandbox.paypal.com/v2/checkout/orders/8KF74291SN313461D/authorize",
"rel": "authorize",
"method": "POST"
}
]
}
Issue was their confusing API documentation.
order_application_context should be changed to: application_context in the API Call
Related
I am currently trying the Orders API of PayPal using Postman, but cannot capture any payment.
For now, I could get the access token, set it to a collection variable, then created orders using (note the access token is set in the Authorization tab):
POST https://api-m.sandbox.paypal.com/v2/checkout/orders
Body:
{
"intent": "CAPTURE",
"purchase_units": [
{
"amount": {
"currency_code": "USD",
"value": "10.00"
}
}
]
}
The request was successful with response body:
{
"id": "<random-id>",
"status": "CREATED",
"links": [
{
"href": "https://api.sandbox.paypal.com/v2/checkout/orders/<random-id>",
"rel": "self",
"method": "GET"
},
{
"href": "https://www.sandbox.paypal.com/checkoutnow?token=<random-id>",
"rel": "approve",
"method": "GET"
},
{
"href": "https://api.sandbox.paypal.com/v2/checkout/orders/<random-id>",
"rel": "update",
"method": "PATCH"
},
{
"href": "https://api.sandbox.paypal.com/v2/checkout/orders/<random-id>/capture",
"rel": "capture",
"method": "POST"
}
]
}
Then I proceeded to rel:approve's link using a browser https://www.sandbox.paypal.com/checkoutnow?token=<random-id> and signed in with my sandbox account. It shows me the usual payment window but when I pressed the "Continue" button, it tried to redirect to the return page but instead, refreshed the page itself.
When I tryed to check the order using rel:self's link: GET https://api.sandbox.paypal.com/v2/checkout/orders/<random-id>. It correctly showed the sandbox account's shipping details (name and address), but the status remained CREATED (not APPROVED or COMPLETED):
{
"id": "<random-id>",
"intent": "CAPTURE",
"status": "CREATED",
"purchase_units": [
{
"reference_id": "default",
"amount": {
"currency_code": "USD",
"value": "10.00"
},
"payee": {
"email_address": "<payee-email>",
"merchant_id": "<payee-id>"
},
"shipping": {
"name": {
"full_name": "<payer-name>"
},
"address": {
"address_line_1": "<payer-address-1>",
"address_line_2": "<payer-address-2>",
"admin_area_2": "<payer-address-3>",
"admin_area_1": "<payer-address-4>",
"postal_code": "<payer-address-5>",
"country_code": "<payer-address-6>"
}
}
}
],
"create_time": "<time-of-post-request>",
"links": [
{
"href": "https://api.sandbox.paypal.com/v2/checkout/orders/<random-id>",
"rel": "self",
"method": "GET"
},
{
"href": "https://www.sandbox.paypal.com/checkoutnow?token=<random-id>",
"rel": "approve",
"method": "GET"
},
{
"href": "https://api.sandbox.paypal.com/v2/checkout/orders/<random-id>",
"rel": "update",
"method": "PATCH"
},
{
"href": "https://api.sandbox.paypal.com/v2/checkout/orders/<random-id>/capture",
"rel": "capture",
"method": "POST"
}
]
}
When I tried to capture the payment using rel:caputure's link: POST https://api.sandbox.paypal.com/v2/checkout/orders/<random-id>/capture with header Content Type: application/json and empty body, it said "payer has not approved the Order for payment", despite I getting the shipping details from the GET request before:
{
"name": "UNPROCESSABLE_ENTITY",
"details": [
{
"issue": "ORDER_NOT_APPROVED",
"description": "Payer has not yet approved the Order for payment. Please redirect the payer to the 'rel':'approve' url returned as part of the HATEOAS links within the Create Order call or provide a valid payment_source in the request."
}
],
"message": "The requested action could not be performed, semantically incorrect, or failed business validation.",
"debug_id": "6a10ea489ffce",
"links": [
{
"href": "https://developer.paypal.com/docs/api/orders/v2/#error-ORDER_NOT_APPROVED",
"rel": "information_link",
"method": "GET"
}
]
}
I have three questions:
Was I using the Orders API correctly? Did I miss some HTTP requests and/or some crucial steps?
I had the return URL set for my sandbox application, why did the payment page not redirect me but instead refreshed itself? Did I miss some setup beforehand?
Why did I fail to capture the payment like above?
P.S. After some digging I think I might be missing the authorize payment step but I have no idea how to do it. (Client-side request? Server-side request?)
I proceeded to rel:approve's link .. when I pressed the "Continue" button, it tried to redirect to the return page but instead, refreshed the page itself.
You did not specify a return_url , so there is nowhere to return to. Refreshing is all that can be done.
What you should do is not redirect to an approval URL, and integrate with no redirects. For this make two routes on your server, one for 'Create Order' and one for 'Capture Order', documented here. These routes should return only JSON data (no HTML or text). The latter one should (on success) store the payment details in your database before it does the return (particularly purchase_units[0].payments.captures[0].id, the PayPal transaction ID)
Pair those two routes with the following approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server
I was also having trouble with this issue, I solved it by expanding the request body, much like #preston-phx said, with the return URL, and it looked something like this:
{
"intent": "CAPTURE",
"payer": {
"email_address": requestBody.payer_email
},
"purchase_units": [{
"amount": {
"currency_code": "USD",
"value": requestBody.amount
},
"payee": {
"email_address": requestBody.payee_email
},
"payment_instruction": {
"disbursement_mode": "INSTANT", // can be INSTANT or DELAYED
"platform_fees": [
{
"amount": {
"currency_code": "USD",
"value": calculateFeesFromAmount(requestBody.amount)
}
}
]
}
}],
"redirect_urls": {
"return_url": "https://example.com/paypalpay/order/approved",
"cancel_url": "https://example.com/paypalpay/order/cancelled"
},
"application_context": {
"brand_name": "Header for payment page",
"locale": "en-US",
"landing_page": "BILLING", // can be NO_PREFERENCE, LOGIN, BILLING
"shipping_preference": "NO_SHIPPING" // because I didn't want shipping info on the page,
"user_action": "PAY_NOW", // Button name, can be PAY_NOW or CONTINUE
"return_url": "https://example.com/paypalpay/order/approved",
"cancel_url": "https://example.com/paypalpay/order/cancelled"
}
}
This also helped me customise the payment page to an extent. I hope Paypal folks include these in the docs at the correct places, most of devs have to dig through a lot of documentation to create an extensive, usable request body.
I wrote some PowerShell functions to help me create user stories a bit faster, and this all works great, but now I am stuck figuring out how to create Tasks for a User Story/Work Item, and obviously having them be assigned to a specific Work Item.
I also can't find any documentation describing this.
I almost imagine that I need use the uri "https://dev.azure.com/$($Organisation)/$Project/_apis/wit/workitems/`$Task?api-version=5.1" but I can't see how to associate it with a work item as part of this, or after.
Can anyone help or point me at some actual documentation for this, please?
Edit: While looking for something else, I stumbled across this, but sadly that errors out for me, so it might be deprecated by now...
Edit; Thanks for the help everyone. This now works for me
This is my code in case it becomes useful for someone some day in the future:
#96116 is the parent work item, 96113 the child task
$ContentType = "application/json-patch+json"
$Token = System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($PersonalAccessToken)"))
$Header = #{Authorization = 'Basic ' + $Token;accept=$ContentType}
$uri = "https://dev.azure.com/$Organisation/$Project/_apis/wit/workitems/96113?api-version=6.1-preview.3"
$body= #'
[
{
"op": "add",
"path": "/relations/-",
"value": {
"rel": "System.LinkTypes.Hierarchy-Reverse",
"url": "https://dev.azure.com/$Organisation/$Project/_apis/wit/workitems/96113",
"attributes": {
"isLocked": false,
"name": "Parent"
}
}
}
]
'#
Invoke-RestMethod -Uri $uri -Method PATCH -Headers $Header -Body $Body -ContentType $contentType
You can follow the steps below to create a new Task, and link a specified User Story as the Parent of this new Task:
Use the endpoint "Work Items - Create" to create the new Task.
Use the endpoint "Work Items - Update" to link the specified User Story as the Parent.
Request URI
PATCH https://dev.azure.com/{organization}/{project}/_apis/wit/workitems/{id}?api-version=6.1-preview.3
Required Header
Content-Type: application/json-patch+json
Request Body
[
{
"op": "add",
"path": "/relations/-",
"value": {
"rel": "System.LinkTypes.Hierarchy-Reverse",
// This is the URL of the linked parent work item.
"url": "https://dev.azure.com/{organization}/{project}/_apis/wit/workItems/{parent work item ID}",
"attributes": {
"isLocked": false,
"name": "Parent"
}
}
}
]
I have tested this method, it can work fine as expected.
As mentioned above, adding a relation can be done after creation with a separate PATCH request, but you can also combine multiple Work Item Tracking requests in a single call. You need to POST to the batch endpoint and send an array of JsonPatchDocuments:
PATCH https://dev.azure.com/{organization}/{project}/_apis/wit/$batch?api-version=2.2
"Content-Type": "application/json"
"Accept": "application/json"
"Authorization": "Basic {PAT}"
[
{
"method": "PATCH",
// Replace $Task below with the WIT you want to create
"uri": "/{Project}/_apis/wit/workitems/$Task?api-version=2.2",
"headers": { "Content-Type": "application/json-patch+json" },
"body": [
{ "op": "add", "path": "/fields/System.Title", "value": "Customer can sign in using their Microsoft Account" },
// Indicates new work item instead of an update. Each new work item uses a unique negative number in the batch.
{ "op": "add", "path": "/id", "value": "-1" },
{
"op": "add",
"path": "/relations/-",
"value": {
"rel": "System.LinkTypes.Hierarchy-Reverse",
"url": "https://dev.azure.com/{organization}/{project}_apis/wit/workitems/{work item id to link to}"
}
}
]
}
]
With this API you can also create a tree of work items in a single call. You use the negative IDs to link workitems together and they ge translated to their real work item ids as the batch is executed.
Docsr for the batch API are here:
Work Item Tracking - Batch REST API
It looks like Microsoft has documentation for creating, deleting, and updating work items.
Your guess was close. Here's the provided example:
Request
POST https://dev.azure.com/fabrikam/{project}/_apis/wit/workitems/${type}?api-version=6.1-preview.3
Body
[
{
"op": "add",
"path": "/fields/System.Title",
"from": null,
"value": "Sample task"
}
]
Response
{
"id": 131489,
"rev": 1,
"fields": {
"System.AreaPath": "CustomProcessPrj",
"System.TeamProject": "CustomProcessPrj",
"System.IterationPath": "CustomProcessPrj",
"System.WorkItemType": "Task",
"System.State": "New",
"System.Reason": "New",
"System.CreatedDate": "2017-10-06T01:04:51.57Z",
"System.CreatedBy": {
"displayName": "Jamal Hartnett",
"url": "https://vssps.dev.azure.com/fabrikam/_apis/Identities/d291b0c4-a05c-4ea6-8df1-4b41d5f39eff",
"_links": {
"avatar": {
"href": "https://dev.azure.com/mseng/_apis/GraphProfile/MemberAvatars/aad.YTkzODFkODYtNTYxYS03ZDdiLWJjM2QtZDUzMjllMjM5OTAz"
}
},
"id": "d291b0c4-a05c-4ea6-8df1-4b41d5f39eff",
"uniqueName": "fabrikamfiber4#hotmail.com",
"imageUrl": "https://dev.azure.com/fabrikam/_api/_common/identityImage?id=d291b0c4-a05c-4ea6-8df1-4b41d5f39eff",
"descriptor": "aad.YTkzODFkODYtNTYxYS03ZDdiLWJjM2QtZDUzMjllMjM5OTAz"
},
"System.ChangedDate": "2017-10-06T01:04:51.57Z",
"System.ChangedBy": {
"displayName": "Jamal Hartnett",
"url": "https://vssps.dev.azure.com/fabrikam/_apis/Identities/d291b0c4-a05c-4ea6-8df1-4b41d5f39eff",
"_links": {
"avatar": {
"href": "https://dev.azure.com/mseng/_apis/GraphProfile/MemberAvatars/aad.YTkzODFkODYtNTYxYS03ZDdiLWJjM2QtZDUzMjllMjM5OTAz"
}
},
"id": "d291b0c4-a05c-4ea6-8df1-4b41d5f39eff",
"uniqueName": "fabrikamfiber4#hotmail.com",
"imageUrl": "https://dev.azure.com/fabrikam/_api/_common/identityImage?id=d291b0c4-a05c-4ea6-8df1-4b41d5f39eff",
"descriptor": "aad.YTkzODFkODYtNTYxYS03ZDdiLWJjM2QtZDUzMjllMjM5OTAz"
},
"System.Title": "Sample task",
"Microsoft.VSTS.Common.StateChangeDate": "2017-10-06T01:04:51.57Z",
"Microsoft.VSTS.Common.Priority": 2
},
"_links": {
"self": {
"href": "https://dev.azure.com/fabrikam/_apis/wit/workItems/131489"
},
"workItemUpdates": {
"href": "https://dev.azure.com/fabrikam/_apis/wit/workItems/131489/updates"
},
"workItemRevisions": {
"href": "https://dev.azure.com/fabrikam/_apis/wit/workItems/131489/revisions"
},
"workItemHistory": {
"href": "https://dev.azure.com/fabrikam/_apis/wit/workItems/131489/history"
},
"html": {
"href": "https://dev.azure.com/fabrikam/web/wi.aspx?pcguid=20cda608-32f0-4e6e-9b7c-8def7b38d15a&id=131489"
},
"workItemType": {
"href": "https://dev.azure.com/fabrikam/aaee31d9-14cf-48b9-a92b-3f1446c13f80/_apis/wit/workItemTypes/Task"
},
"fields": {
"href": "https://dev.azure.com/fabrikam/_apis/wit/fields"
}
},
"url": "https://dev.azure.com/fabrikam/_apis/wit/workItems/131489"
}
As an EU based seller I need to charge tax based on customer country tax rates and rules. That means that when I create subscription I need to specify either tax rate (percentage or amount) or have the ability to override subscription price. When using Stripe one just needs to specify tax_percent beside plan_id when creating subscription.
So far I wasn't able to do the same using PayPal Subscriptions API and their smart buttons. Tax rate can be set when creating plan but I need to be able to set tax percentage per subscription.
Sample smart button JS code:
paypal.Buttons({
createSubscription: function(data, actions) {
return actions.subscription.create({
'plan_id': 'P-2UF78835G6983425GLSM44MA',
// I'd like to be able to set tax rate here somehow
});
}
}).render('#paypal-button-container');
No luck setting up tax directly using Subscriptions API either:
curl -v -k -X POST https://api.sandbox.paypal.com/v1/billing/subscriptions \
-H "Accept: application/json" \
-H "Authorization: Bearer Access-Token" \
-H "Content-Type: application/json" \
-d '{
"plan_id": "P-2UF78835G6983425GLSM44MA",
"application_context": {
"brand_name": "example",
"user_action": "SUBSCRIBE_NOW",
"payment_method": {
"payer_selected": "PAYPAL",
"payee_preferred": "IMMEDIATE_PAYMENT_REQUIRED"
},
"return_url": "https://example.com/returnUrl",
"cancel_url": "https://example.com/cancelUrl"
}
}'
Am I missing something, thinking about this incorrectly or did PayPal "forgot" to implement basic thing like tax rate and therefore make their new subscriptions API unusable for VAT MOSS scenarios?
You can add the tax override to the plan node as shown below
<script>
paypal.Buttons({
createSubscription: function(data, actions) {
return actions.subscription.create({
'plan_id': 'YOUR_PLAN_ID_HERE', // Creates the subscription
'plan': {
'taxes': {
'percentage': '2.9',
'inclusive': false
}}
});
},
onApprove: function(data, actions) {
alert('You have successfully created subscription ' + data.subscriptionID); // Optional message given to subscriber
}
}).render('#paypal-button-container'); // Renders the PayPal button
</script>
It's an old topic and still not possible. PayPal doesn't support taxes with subscriptions. You can price your subscription so it has the VAT included in it. Mention that the price includes VAT before a user is redirected to payment.
I highly recommend not to implement the tax rules yourself. Better let a 3rd party API handle correct calculations.
https://vatstack.com/rates
https://quaderno.io/checkout
https://www.octobat.com/products/vat-gst-sales-tax-engine
Recently I found out that this is possible. Not sure if this is something added fairly recently or was this option there all along.
While creating a subscription you can override a plan and set the tax percentage inline.
curl -v -k -X POST https://api.sandbox.paypal.com/v1/billing/subscriptions \
-H "Accept: application/json" \
-H "Authorization: Bearer Access-Token" \
-H "Content-Type: application/json" \
-d '{
"plan_id": "#PLANID",
...
"plan": {
"taxes": {
"percentage": "19",
"inclusive": false
}
}
}'
Taxes seem to be included in the Plan entity.
https://developer.paypal.com/docs/subscriptions/full-integration/plan-management/#show-plan-details
curl -v -X GET https://api-m.sandbox.paypal.com/v1/billing/plans/P-2UF78835G6983425GLSM44MA \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <Access-Token>
{
"id": "P-2UF78835G6983425GLSM44MA",
"product_id": "PROD-6XB24663H4094933M",
"name": "Basic Plan",
"status": "ACTIVE",
"description": "Basic plan",
"billing_cycles": [
{
"frequency": {
"interval_unit": "MONTH",
"interval_count": 1
},
"tenure_type": "TRIAL",
"sequence": 1,
"total_cycles": 1
},
{
"pricing_scheme": {
"fixed_price": {
"currency_code": "USD",
"value": "10.0"
}
},
"frequency": {
"interval_unit": "MONTH",
"interval_count": 1
},
"tenure_type": "REGULAR",
"sequence": 2,
"total_cycles": 12
}
],
"payment_preferences": {
"auto_bill_outstanding": true,
"setup_fee": {
"currency_code": "USD",
"value": "10.0"
},
"setup_fee_failure_action": "CONTINUE",
"payment_failure_threshold": 3
},
----------------------------------------
"taxes": {
"percentage": "10.0",
"inclusive": false
},
----------------------------------------
"quantity_supported": false,
"create_time": "2020-02-26T07:01:04Z",
"update_time": "2020-02-26T07:01:04Z",
"links": [
{
"href": "https://api-m.sandbox.paypal.com/v1/billing/plans/P-2UF78835G6983425GLSM44MA",
"rel": "self",
"method": "GET"
},
{
"href": "https://api-m.sandbox.paypal.com/v1/billing/plans/P-2UF78835G6983425GLSM44MA",
"rel": "edit",
"method": "PATCH"
},
{
"href": "https://api-m.sandbox.paypal.com/v1/billing/plans/P-2UF78835G6983425GLSM44MA/deactivate",
"rel": "self",
"method": "POST"
}
]
}
When creating a subscription, it would be nice to return the subscription ID.
For instance, the following code doesn't return anything :
curl localhost:1026/v2/subscriptions -s -S --header 'Content-Type: application/json' \
-d #- <<EOF
{
"description": "A subscription to get info about Room1",
"subject": {
"entities": [
{
"id": "Room1",
"type": "Room"
}
],
"condition": {
"attrs": [
"pressure"
]
}
},
"notification": {
"http": {
"url": "http://localhost:1028/accumulate"
},
"attrs": [
"temperature"
]
},
"expires": "2040-01-01T14:00:00.00Z",
"throttling": 5
}
EOF
In the subscription case, the resource id is generated server-side (with difference to the entities endpoint, where the id is decided client-side).
It would be nice to return it in the POST call, is there any way to do this?
Subscription ID is retrieved in Location header in the response to the subscription creation request, eg:
Location: /v2/subscriptions/5b991dfa12f473cee6651a1a
More details in the NGSIv2 API specification (check "Create Subscription" section).
I'm currently attempting to integrate my app with Future Payments and in the documentation, it mentions:
Unlike the standard REST API docs that demonstrate a one time payment,
a future payment doesn't require you to separately get payment
approval after getting initial user consent. The payment is
pre-approved by the user.
So looking at the example, I should get a response which contains:
"state": "authorized"
"links": [
{
"href": "https://api.paypal.com/v1/payments/authorization/4TD55050SV609544L",
"method": "GET",
"rel": "self"
},
{
"href": "https://api.paypal.com/v1/payments/authorization/4TD55050SV609544L/capture",
"method": "POST",
"rel": "capture"
},
{
"href": "https://api.paypal.com/v1/payments/authorization/4TD55050SV609544L/void",
"method": "POST",
"rel": "void"
},
{
"href": "https://api.paypal.com/v1/payments/authorization/4TD55050SV609544L/reauthorize",
"method": "POST",
"rel": "reauthorize"
},
{
"href": "https://api.paypal.com/v1/payments/payment/PAY-2C433581AX997613HKJFBVLI",
"method": "GET",
"rel": "parent_payment"
}
],
And from what I understand, the transaction, along with the Client Metadata ID and Access Token in the request header, should be automatically processed, without further approval, because the user has already given consent.
So if the transaction intent is 'sale', the success response 'state' would be 'completed' and if the intent is 'authorize', the state would be 'authorized'.
This makes sense, but when testing my app, I'm getting a response with an approval url that I need to redirect the user to and the state is 'created' not 'completed/authorized' ? -
"state": "created"
"create_time": "2016-03-20T00:42:25Z",
"links": [
{
"href": "https://api.sandbox.paypal.com/v1/payments/payment/PAY-3NA62949E72063722K3W7D4I",
"rel": "self",
"method": "GET"
},
{
"href": "https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=EC-41A06151Y6402822R",
"rel": "approval_url",
"method": "REDIRECT"
},
{
"href": "https://api.sandbox.paypal.com/v1/payments/payment/PAY-3NA62949E72063722K3W7D4I/execute",
"rel": "execute",
"method": "POST"
}
]
I managed to resolve the issue by removing express_checkout from the scope. If this is enabled, it appears to override future payments so it no longer works and uses the express checkout pay flow instead.