The question is vague at parts, so some of this answer is likewise necessarily vague.
So, can I see a "payment method" as a Class?
In pure OOP, everything is a class or a method. A Payment Method class would make sense, especially as there are distinct payment methods.
I think the Class can have Attributes like total, subtotal, discount, tpv selection, result, error messages... but... some of them are already part of my Basket class.
Boil payment methods down to their essential constituents and behaviors. Ask yourself questions like: are monetary quantities really a part of how someone pays, or are they a part of what is being paid? (Answer to this specific question: they are part of a payment, not a payment method) When a payment is made, payment info will be needed, but it can be passed to whichever methods need it (perhaps in a Payment object, which represents a monetary amount sent from a buyer to a seller, or in an Order object, or an Order object could implement a Payment interface, though the last wouldn't model the real world injectively).
And how can use it? calling its functions from outside and sending a lot of parameters such as credit card requirements? or forcing the Class to obtain those values outside, in the preferences file?
If payment requirements are part of payment methods, they should be properties of payment methods. As for how payment method objects are initialized, the dependency injection technique (where a separate class is responsible for determining which payment method, among other specific classes, should be involved in a transaction and set them up) could be applied, though it isn't always the best choice. You could also have a controller that responds to an action from the user (i.e. selecting a payment method) by reading the configuration data and creating the payment method object, passing said data to the payment method.
There are a couple valid approaches to using a payment method object. Any time an action involves multiple objects and one isn't a clear actor (i.e. the one that should perform the action), you could use a free function (i.e. a non-method function) that calls the necessary methods of the appropriate objects. If behavior of the function varies depending on the run-time types of multiple objects, you'd use multi-methods (if possible; not many languages support multi-methods natively, though you can simulate it in many languages with certain patterns, such as double dispatch). Other possibilities include having a controller as the primary actor.
One concept that can help when implementing designs are the access rules made explicit in capabilities programming: objects can access other objects that they create, are created knowing (i.e. passed to their constructor) or are introduced to. These rules inform techniques such as dependency injection, Model-View-Controller (MVC) and so on.
A different class for each payment method, or a big class with all of them...
Somewhere in between. Anything that is common to all payment methods (such as an action URL) should go in a base class. If a payment method needs to override the common behavior or needs a field that other methods don't, subclass the base payment method. For consistency's sake, you could extend the base class for all payment methods, though some subclasses might not override anything.
