Clarification about Sprint Backlog and Sprint Goal

It isn't the Sprint Goal which ought to be flexible. Flexibility ought to lie in the forecast of work required to achieve it.

A good Sprint Goal makes the selection of work on the Sprint Backlog coherent and gives the team a reason to work together that Sprint.

Paying by credit card might be a good Sprint Goal in so far as it allows a clear commitment to be made by the team, and provides flexibility regarding the providers, intermediaries and technologies used in the solution.

I think your understanding is generally correct.

One of the mistakes that I see when thinking about the Sprint Backlog is around the set of Product Backlog Items that are selected for the Sprint, but I'm not sure if you are making this mistake or not. Some people believe that there is a close relationship between the set of selected Product Backlog Items and the Sprint Goal. I don't believe this to be true. The Sprint Goal does help guide the selection of Product Backlog Items. At the end of Sprint Planning, however, there may only be one or two of the Product Backlog Items that are believed to be necessary to accomplish the Sprint Goal. There are clear separations between the Sprint Goal, the set of Product Backlog Items selected for the Sprint, and the team's capacity. At Sprint Planning, you craft the goal as one that is achievable within the Sprint timebox. Then you select the Product Backlog Items that the team believes are necessary to accomplish the goal. You should check to see that the selected items still make sense for completion within the Sprint. If you still have remaining capacity, the team can decide to select some other Product Backlog Items so they have a clear picture of what to work on after the goal or they can defer this decision until during the Sprint, as the items in the Sprint Backlog all become Done.

Going to the specific example of a Sprint Goal of "allow the customer to pay with a credit card in order to create his order", that feels like a Sprint Goal that can be accomplished by implementing a very small number of Product Backlog Items. Depending on how you slice it, you may have a PBI around the happy path and then additional PBIs to handle various error conditions (or perhaps handle them more gracefully). If it is critical to stakeholders that credit card payments are delivered and the team determines that this Sprint Goal can be accomplished at some point within the Sprint timebox, though, it could be a reasonable Sprint Goal. If it is a straightforward goal, it may be accomplished well before the Sprint concludes. The team may choose other work to fill the remainder of the timebox. Some examples of things the team could do include pulling in additional Product Backlog Items that are ready, refining the Product Backlog, paying down technical debt, building skills and improving cross-functionality, or even just taking time off to rest and ensure a long-term sustainable pace.