Misc Google Checkout fixes #21
Conversation
The previous method required loading all billing_tags - this means to configure all integrations, even if they are unused (i.e. your settings file needs to contain the PayPal config even if you are only using Google Checkout.
|
The documentation fixes are in. Regarding registering the templatetags separately, I will be doing it in a separate version. Am planning some changes to the organization of the library. Please hold on. |
|
Great, thanks for letting me know. Keen to see what's coming in the re-organisation! |
Usage::
gc.add_fields({
'private_data': 'some private data',
...
})
Previously it was sending the signal as soon as the order notification was received (i.e. possibly before the user paid for it).
|
Any word on when this will be merged or when the reorganization will be finished? |
|
@mattbriancon We have an internal hackathon scheduled this Friday and I am planning to work on merchant. Please hold tight for a couple of days. |
|
@theju That sounds great! I look forward to seeing how everything turns out. A question though: is the Google Checkout API version 2.5 (with the Notification HIstory and Order Processing APIs) within the scope of the hackathon? If not, I'd be willing to work on it but probably wouldn't be able to get anything finished until next week. |
|
I am done with the reorganization for now mainly in the settings attributes and the template tag usage and merged this pull request. You can send me your pull request for the new API but please keep a lookout for #29. I am slightly doubtful if merchant should bundle models because the payment processors are very notorious in changing data (or types) very often and there is no standard support for db migrations as yet. Would like to know your thoughts. |
|
Personally I think merchant should bundle the models, except where we rely on third-party modules like django-paypal. This should be simple enough with something like South - happy to help out here if necessary, we use South a lot at my day job. Perhaps each backend should have its own version number, which ties in to the payment processors versioning scheme? That should make it easy to ensure one is using the correct version of merchant, and that merchant is valid with the current version of the payment processors API. |
|
@mikery Thanks for the reply. The issue is not with south but with the versioning of backends. I haven't given it any thought and would love to hear more details on the versioning scheme you suggest. Do you mean to imply that merchant should support multiple versions of the same backend? |
|
The biggest issue with the newest Google Checkout API is the change in how data is sent from Google to merchant. Rather than POSTing to a URL (which requires SSL), API 2.5 now only*** sends a serial number which is then used to query their new Notification History API. I'm not familiar with how the other integrations work in merchant but this seems like a pretty drastic change (especially considering that at scale you'd want to throw the serial numbers to a queue to be processed async). *** You can still use the old method but this is now the recommended way. |
Hi,
This pull request fixes the following issues:
Template tags can be loaded individually, rather than needing to load the tags for all integrations:
{% load google_checkout from google_checkout_tags %}
This means you do not need to setup the PayPal config if you are only using Google Checkout (as billing_tags will raise an exception if PayPal settings are not found in settings.py).
This is a great library, thank you! :)