What was I thinking?

An Item knows how much it's worth, but doesn't specify in what currency. It should, optionally, take a currency, so that when a checkout is created the values are not blindly summed up.

Since we don't support signature authentication, we should support certificate-based authentication.

Requirements:

• The test suite should have a client certificate, and the client certificate should be checked by the mock sandbox.

Express Checkout for Digital Goods has a few peculiarities. You can support all of these yourself by just using Express Checkout support, but it'd be nicer if we had an API tailored for Digital Goods support.

• Only a single payment request is supported (normally up to 10)
• Quantity should always be specified (although that probably means the normal EC support should, too)
• All items must have their category set to "Digital".
• All payment request payment actions must be sales if specified. It's not a bug if normal EC support always mentions the action, so that should be the default behavior. Digital Goods specific support should just verify that this is the case.
• All item details must be specified when completing a checkout, otherwise you miss out on the micropayment rate. Again, EC should always do this.

txievery.expresscheckout.encode and t.e.decode are not very OO. Maybe they should be merged back.

Composition is great!

Once we have a Sandbox test suite, there should be a mock PayPal server for running it against.

Try:

from txievery.expresscheckout.api import PaymentRequest
pr = PaymentRequest("100.123456", "USD")
assert str(pr) == "100.12"

Although this is ostensibly the correct behavior (the Paypal spec says so), it's still throwing away data.

PayPal provides a sandbox for testing implementations again. There should be a test suite that verifies txievery against the sandbox.

This should not be part of the unit tests, because it requires:

• many real requests to the sandbox, which may be very slow
• credentials for using the sandbox, that not everyone has

Modifying the return URL is the preferred way to link users: you come up with a nonce value, store it, set it in the return URL, and then when they visit that URL you know who they are.

Right now, there's not a lot of options for changing the return URL. This is a Bad Thing(TM).

The alternative to modifying the URL is setting a cookie, which isn't very good...

It is unknown if thsi affects normal Express Checkout too.

The failure mode is, of course, horrible. It just says "loading" and refuses to load the appropriate page. Genius.