Bug 138584 - Multiple credit-card charges for single Magnatunes purchase
Summary: Multiple credit-card charges for single Magnatunes purchase
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 1.4.4
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-09 15:20 UTC by Ana Guerrero
Modified: 2006-12-09 19:28 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ana Guerrero 2006-12-09 15:20:12 UTC
Version:           1.4.4 (using KDE KDE 3.5.5)
Installed from:    Debian testing/unstable Packages
OS:                Linux

Bug submited in the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402309

When you make a purchase using the Magnatunes integrated store, Amarok 
issues the payment instruction multiple times, resulting in overcharging.

While Magnatunes are very good at picking up on this (it seems it's an 
upstream bug that's happening to a number of people) and reversing the 
charge, it strikes me that a bug that costs users *actual money* 
deserves at the very least a "serious" tag. (Credit card fees and 
currency exchange rates means you don't get the full amount back if 
you're not paying in US dollars.)

Reproducing the problem: go to the Magnatunes integrated store, 
right-click an album title and select "purchase". Enter your credit card 
details and click "purchase".

Expected behaviour: get charged the chosen amount, once.

Observed behaviour: get a single confirmation that the transaction has 
been a success, with links to download the track. But then emails come 
through indicating that the transaction has in fact been processed more 
than once - I'm currently looking at three separate confirmation emails 
for a single purchase, with three separate charges to my card.
Comment 1 Mark Kretschmann 2006-12-09 19:28:25 UTC
Thanks, this is already fixed in SVN.