Inna fb28e97307 store: devolver por Stripe/SumUp lo no entregado de una compra con tarjeta
Faltaba la otra mitad de 0be3dc5: con saldo ya se reembolsaba lo que no llegaba
a enviarse, pero con tarjeta el dinero lo tiene la pasarela y el cliente se
quedaba pagando de más. Ambas tienen API de reembolso parcial, así que ahora
`fulfill` puede pedir que se devuelva un importe y lo hace quien conoce la
pasarela (lib/fulfill para Stripe, lib/sumup para SumUp).

Para saber CUÁNTO devolver hay que saber qué costó cada entrada, así que el
pedido pasa a guardarse como `itemId:qty:precio:moneda`. Releer el precio del
catálogo al entregar no vale por dos razones: 114 item_id son ambiguos (el mismo
objeto se vende a 50 PV y a 100 PD), y hay que devolver lo que se COBRÓ, no lo
que valga el ítem el día de la entrega. Los pedidos con el formato viejo se
entregan igual, pero no se puede calcular su reembolso: se registra para hacerlo
a mano.

`fulfill` devuelve ahora `boolean | {ok, refundEur}`; los servicios que no
entregan a medias siguen devolviendo boolean y no se tocan.

Sobre SumUp, todo comprobado contra su API en sandbox y nada de esto está en
sitios obvios:
 - El reembolso NO va por referencia de checkout sino por transacción.
 - Hay que usar el endpoint de v1.0; el viejo `/v0.1/me/refund/{txn}` responde
   409 a CUALQUIER reembolso parcial (el total sí funciona).
 - v1.0 quiere el importe en CÉNTIMOS y ENTERO, al revés que el resto de la API
   v0.1, que usa euros. Y mandar 0.10 en vez de 10 no da error: se trunca a 0,
   SumUp lo lee como "sin importe" y DEVUELVE EL PAGO ENTERO. Casi me lo comí.
 - Hay un mínimo por reembolso (20 cts en esta cuenta, la API lo dice en
   `min_refundable_amount`): por debajo responde 400 y se registra para hacerlo
   a mano.
El host sale de SUMUP_API_BASE (por defecto api.sumup.com) en vez de ir a fuego.

Verificado de punta a punta con pagos reales de prueba, parcheando el SOAP para
que solo saliera el primer correo:
 - Stripe (sk_test): pagados 1,30 €, entregadas 12/13 -> reembolso de 0,10 €,
   status succeeded en la API de Stripe.
 - SumUp (sandbox): pagados 1,50 €, entregadas 12/15 -> evento REFUND 0.3
   REFUNDED en la API de SumUp.

De paso: el concepto del cobro decía "1 objeto" al comprar 15 copias (contaba
líneas, no copias).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-15 10:57:00 +00:00
2024-11-12 09:16:30 +01:00
2024-11-12 09:17:08 +01:00
2024-11-12 09:17:08 +01:00

Nova WoW

Portal web (Django) para un servidor de World of Warcraft basado en AzerothCore.

  • Python: 3.14
  • Framework: Django 6.0
  • Base de datos: MySQL (4 bases: la del portal django_wow + las de AzerothCore acore_auth, acore_characters, acore_world)

1. Requisitos

  • Python 3.14 y venv
  • MySQL/MariaDB accesible
  • Librerías de sistema para compilar algunas dependencias:
sudo apt install python3.14-venv python3.14-dev build-essential pkg-config \
    default-libmysqlclient-dev libgmp-dev libmpfr-dev libmpc-dev libjpeg-dev zlib1g-dev

2. Puesta en marcha (desarrollo)

git clone https://git.nightspire.gg/Inna/NovaWoW.git
cd NovaWoW

# Entorno virtual
python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install -r requirements.txt

# Variables de entorno
cp .env.example .env
# edita .env con tus credenciales reales (ver sección 3)

# Migraciones y arranque
python manage.py migrate
python manage.py createsuperuser        # opcional
python manage.py runserver

La app queda en http://127.0.0.1:8000


3. Configuración (.env)

Toda la configuración sensible se lee de variables de entorno mediante python-dotenv. Copia .env.example a .env y rellena los valores. El .env no se versiona.

Variable Descripción
DJANGO_SECRET_KEY Clave secreta de Django. Genera una nueva (ver abajo).
DJANGO_DEBUG True en desarrollo, False en producción.
DB_USER / DB_PASSWORD Credenciales MySQL (compartidas por las 4 BBDD).
DB_HOST / DB_PORT Host y puerto de MySQL.
DB_NAME_DEFAULT BD del portal (por defecto django_wow).
DB_NAME_AUTH / DB_NAME_CHARACTERS / DB_NAME_WORLD BBDD de AzerothCore.
AC_SOAP_* Conexión SOAP a AzerothCore (crear cuentas, etc.).
SUMUP_* / STRIPE_* Pasarelas de pago.
EMAIL_HOST_USER / EMAIL_HOST_PASSWORD SMTP de Gmail (App Password).

Generar una SECRET_KEY nueva:

python -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"

4. Producción

# Recopilar estáticos
python manage.py collectstatic --noinput

# Servir con gunicorn (4 workers)
gunicorn novawow.wsgi:application --bind 0.0.0.0:8000 --workers 4

Recomendaciones:

  • DJANGO_DEBUG=False y una DJANGO_SECRET_KEY propia y secreta.
  • Poner Nginx delante como proxy inverso y para servir staticfiles/.
  • Revisar ALLOWED_HOSTS y CSRF_TRUSTED_ORIGINS en novawow/settings.py.

5. Docker

Alternativamente, se puede levantar todo con Docker (web + MySQL):

cp .env.example .env      # ajusta los secretos (no las variables DB_*, las fija compose)
docker compose up --build
  • La web queda en http://127.0.0.1:8000
  • El servicio db crea automáticamente las 4 bases de datos.
  • El entrypoint espera a MySQL, aplica migraciones y recopila estáticos antes de arrancar gunicorn.

Ver docker-compose.yml y Dockerfile para los detalles.


6. Notas de seguridad

  • Los secretos que estuvieron hardcodeados en el historial de git deben rotarse (contraseña MySQL/SOAP, App Password de Gmail, claves de Stripe/SumUp).
  • Nunca subas el archivo .env al repositorio.
S
Description
Importado desde GitHub adevopg/NovaWoW
Readme 264 MiB
Languages
Macaulay2 97.3%
TypeScript 2.3%
CSS 0.3%