fb28e97307f920d266566cc2a547399fe451f88e
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>
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 AzerothCoreacore_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=Falsey unaDJANGO_SECRET_KEYpropia y secreta.- Poner Nginx delante como proxy inverso y para servir
staticfiles/. - Revisar
ALLOWED_HOSTSyCSRF_TRUSTED_ORIGINSennovawow/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
dbcrea automáticamente las 4 bases de datos. - El
entrypointespera 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
.enval repositorio.
Description
Languages
Macaulay2
97.3%
TypeScript
2.3%
CSS
0.3%