I been searching this through reading the documentation how to get the promotion attached to the shipping method which I am planning to use the shipping method ID as identifier.
Looks like this code :
dw.order.ShippingLineItem.getShippingPriceAdjustments()
But I don't know how can I get the promotion using the shipping method ID.
Anyone?
PromotionMgr.getActiveCustomerPromotions().getShippingPromotions(shippingMethod : ShippingMethod)
Explanation:
getActiveCustomerPromotions() get all activated promotions for current user (storefront user). You can get global promotions by getActivePromotions()
getShippingPromotions() get promotions will be activated for specific shipping method
Get shipping method via ShippingMgr class.
Related
I could not find info in the documentation on how to grab an order id out of the capture id that I receive from the daily transaction detail report. The only way I found was to check the links field in the capture after the capture gets the request, however, that does not seem like the best way to do it.
Does anyone know how to achieve it directly?
If you are using the Orders V2 API, the Order ID is only used during checkout approval. It is not persisted after transaction creation, and looking up captured payment details with the transaction/capture id: https://developer.paypal.com/docs/api/payments/v2/#captures_get , will not return the Order ID used during checkout, since it is not useful for anything at that point.
The "country" field in the PayPal transaction history CSV exports is almost always empty. However, PayPal must know the country where a transaction originates, and in fact tools such as Putler can display the country for nearly all transactions.
I wish to obtain this data myself, but since the export doesn't appear to have it, should I obtain it by using the API? And which of the APIs wold be appropriate to use for this purpose?
Thanks in advance.
Yes you can probably do this using the API. First you'll need to search your account's transaction history. After that you'll get a list of transaction ID's, you can then retrieve information about a specific ID which includes the country code of the buyer.
You can see more details here: https://developer.paypal.com/docs/classic/express-checkout/ht_searchRetrieveTransactionData-curl-etc/
After switching to the new Facebook local currency API the process is working, but
my server is not involve in the process so i really don't know if the user bought coins cause the payment callback URL is not being called now (using static payment).
I tried to use real time update to get Facebook data but can make it work, what is the best practice to involve the server in the process so it will be aware of the purchase?
I prefer for security reasons to get the update from Facebook and not from my client.
Ok after searching a log i found the solution
There are two primary methods through which you are notified of the outcome of the purchase, and a further method by which you can verify any payment information.
Firstly, Facebook will return details of the order via a JavaScript callback. The data sent to this callback includes:
payment_id, which uniquely identifies the transaction.
quantity, which indicates the amount of the item which was sold.
request_id, optionally, the developer can provide their own unique identification for the transaction when calling our Javascript SDK to render the payment dialog. This value is then returned upon purchase completion.
status, which indicates the current state of the transaction, i.e. 'pending', 'completed', 'failed' etc.
Secondly, Facebook will issue a realtime update notifying the developer that a new order has completed. The developer can subscribe to the payment_object callback to track order completions, using the payment_id as the unique identity parameter for each transaction.
Thirdly, at any time, the payment_id can be used to verify details of a transaction via the Graph API. Details such as the associated user_id, updated_time and amount can be queried, using the payment_id. The Graph API will also allow you to access further details including any refunds or disputes associated with the transaction.
If for some reason both the JavaScript callback and the realtime update fail and you do not receive the payment_id, we also allow you to query the Graph API using the optional request_id parameter, which can be specified by the developer when invoking the Facebook payment dialog.
please refer to:
https://developers.facebook.com/docs/concepts/payments/
and to:
https://developers.facebook.com/docs/howtos/payments/fulfillment/#rtu
I'm using the callback API to prevent someone selecting a non-UK shipping address. I've supplied a callback url, I've set CALLBACKVERSION to 61.0.
When I go into the sandbox and choose an address I know the callback page is being called as I've added code to email me the values submitted to it and the value returned to PayPal. For anything with a SHIPTOCOUNTRY that isn't GB the response is
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1
I've also tried setting a fuller response in case it doesn't like some required field to be missing
METHOD=CallbackResponse&CURRENCYCODE=GBP&L_SHIPPINGOPTIONNAME0=Standard&L_SHIPPINGALABEL0=Standard&L_SHIPPINGAMOUNT0=2.95&L_SHIPPINGOPTIONISDEFAULT0=true&L_SHIPPINGOPTIONNAME1=Express&L_SHIPPINGALABEL1=Express&L_SHIPPINGAMOUNT1=5.95&L_SHIPPINGOPTIONISDEFAULT1=false&NO_SHIPPING_OPTION_DETAILS=1
But it's still allowing non-UK addresses and just using the shipping options set during the initial set up request.
Any suggestions on where I'm going wrong?
After opening a ticket as suggested by PayPal_Patrick the problem was that I was adding the callbackversion in the wrong place. The full response to reject a shipping address on callback is:
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1&CALLBACKVERSION=61
There are different transaction ID's for Buyer and Seller accounts.
I think this might be an issue caused by the country associated with the buyer account being used. I'm going to reach out to the product team for Express Checkout and see if it is intended functionality or not - I don't believe it would be.
If you want to stay updated on the issue I would recommend creating a ticket to PayPal.com/mts, give me the ticket number, I'll grab it and keep you involved.
We're currently looking at implementing Facebooks new subscription payments. We already have a working payment setup for Facebook, and the callback url is set correctly. If I make regular test payment the callback is called correctly.
The setup for testing subscriptions is according to this. But either if I choose the always success or always fail there is no callback made to the payments callback url.
It does return an object that says the subscription is active an has an ID.
{status: "active", subscription_id: 204626XXXXXX}
Is it possible you only get a request sent to the callback URL if the subscription state changes, and you already have an active subscription for the user? I would think you would get a client-side error in this case, but I don't see any evidence that there's an error code for that.
What happens if you make a regular test payment multiple times for the same account?
Facebook subscriptions are not regular purchase.
You will have to setup Real time updates on 'payment_subscriptions' object and listening to those available fields: ('status', 'pending_cancel', 'payment_status', 'last_payment'). See the documentation : http://developers.facebook.com/docs/payments/subscriptions/, there is a section called "Consuming Real time updates"
Each time an user subscribes or cancel (or an implicit renew), you will be hit with the related subscription id. You can then ask the Graph API about this subscription object.
You can also retrieve the list of subscriptions for any user via the Graph Api call on '/payment.subscriptions'
All these calls have to be performed with an App access token.
I must confess this process is quite annoying if you always performed "synchronous" purchases. I did implement subscriptions, this was a loooooong & painful travel ;)
Hope this helps
Subscriptions are mapped to OpenGraph objects on Facebook side, as well as virtual currency, so, I suspect there is no callback made to server side, all that you can do is make some kind of http post (through a form, for example) insde the FB.ui callback and implement the doPost method in a Servlet. That's would be a way to get subscription information into some data source.
Edit: concerning to payments callback, those items which order information are calculated based on OG object, facebook doesn't send a payments_get_items request, so there is no way to get order information after subscription creation. On the other hand, it could be possible that you receive some payments_status_update in the correspondent servlet (I'm talking about servlets because I'm a Java programmer, but the general idea applies for whichever technology you choose)